Работа пользователей с базой данных 1С:Предприятие в клиент-серверном варианте через службы удаленных рабочих столов (RDP) — это классическая и очень популярная схема организации ИТ-инфраструктуры. Однако системные администраторы часто сталкиваются с неприятной проблемой: после закрытия пользователями терминального окна или при случайном обрыве сетевого соединения сеансы на сервере 1С продолжают «висеть». В списке активных пользователей один и тот же сотрудник может дублироваться несколько раз, непроизвольно расходуя программные лицензии и создавая лишнюю нагрузку на сервер. Рассмотрим подробно, почему возникает эта проблема на стыке операционной системы Windows Server и платформы 1С:Предприятие 8.3, а также разберем по шагам проверенные методы ее устранения.
Прежде чем переходить к практическим действиям, проанализируем ситуацию и поймем физику процесса. Когда пользователь подключается к терминальному серверу и запускает 1С, операционная система Windows создает сеанс, в котором выполняются процессы 1cv8c.exe (тонкий клиент) или 1cv8.exe (толстый клиент). В нормальной ситуации при выходе из 1С закрываются связанные процессы, а затем завершается и сама RDP-сессия.
Если же происходит аварийное отключение (например, моргнул интернет) или пользователь просто закрывает окно RDP «крестиком», сессия операционной системы переходит в состояние Disconnected (Отключена). Процессы внутри этой сессии продолжают выполняться. Платформа 1С:Предприятие со своей стороны видит потерю связи с клиентом, но не спешит сразу «убивать» сеанс, переводя его в статус «спящего». Ситуация усугубляется, если в системе задействованы механизмы печати: 32-разрядный клиент 1С на 64-разрядной операционной системе Windows Server обращается к службе печати через специальный транслятор — процесс splwow64.exe. Этот процесс часто блокирует корректное завершение терминальной сессии, оставляя ее в бесконечном ожидании.
Ниже мы подробно разберем пять последовательных шагов, которые помогут полностью решить проблему зависания сессий.
Если на вашем сервере установлена 64-битная версия Windows Server, а пользователи работают с 32-битным клиентом 1С, то при первом же выводе любого документа на печать операционная система запускает процесс splwow64.exe (Thunking Spooler APIs). По умолчанию этот процесс продолжает работать в сессии пользователя в течение некоторого времени после закрытия основных программ, удерживая RDP-сессию от окончательного завершения (Logoff).
Для того чтобы исправить это поведение системы, нам понадобится внести изменения в системный реестр Windows Server. Выполним следующие действия под учетной записью администратора:
regedit и нажмите Enter для запуска Редактора реестра.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs.splwow64.exe. Если такого параметра нет, создайте его: нажмите правой кнопкой мыши на пустом месте в правой части окна, выберите Создать -> Параметр DWORD (32 бита). Назовите его splwow64.exe и присвойте ему значение 0. Это укажет операционной системе, что данный процесс является системным и его нужно принудительно завершать при закрытии пользовательского сеанса.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print.SplWOW64TimeOut. По умолчанию операционная система удерживает этот процесс активным довольно долго. Дважды щелкните по созданному параметру, выберите десятичную систему исчисления и задайте значение 1 (это установит минимальный таймаут удержания процесса в секундах).После внесения этих изменений рекомендуется перезагрузить сервер печати или весь терминальный сервер для вступления настроек в силу.
Часто сеансы 1С остаются активными на сервере приложений просто потому, что сама операционная система Windows Server бесконечно держит RDP-сессию в отключенном состоянии после обрыва связи. Нам необходимо настроить автоматическое завершение таких «заброшенных» сессий.
Проанализируем и настроим локальные групповые политики:
gpedit.msc и нажмите Enter.1 мин или 5 мин). Как только пользователь закроет RDP-клиент крестиком или потеряет интернет-соединение, сервер подождет указанное время и выполнит операцию разлогинивания (Logoff), закрывая все процессы пользователя, включая 1С.Чтобы изменения применились незамедлительно без перезагрузки сервера, откройте командную строку от имени администратора и выполните команду обновления политик:
gpupdate /force
Начиная с версии платформы 8.3.5, фирма 1С реализовала встроенный механизм защиты от неустойчивого сетевого соединения. Если сеанс пользователя аварийно прерывается, сервер 1С не уничтожает его сразу, а переводит в состояние «Спящий». Это позволяет пользователю при быстром восстановлении связи безболезненно продолжить работу с того же места без потери несохраненных данных. Однако по умолчанию спящие сеансы могут оставаться в памяти сервера до 24 часов.
Мы можем принудительно сократить это время в настройках информационной базы:
1200 секунд (20 минут).600 секунд (10 минут).Теперь, если сеанс перейдет в режим сна, сервер 1С автоматически удалит его из списка активных пользователей уже через 10 минут, освобождая лицензии и системные ресурсы.
Чтобы избежать ситуации, когда один и тот же сотрудник под своей учетной записью плодит множество зависших подключений, имеет смысл ограничить количество одновременных сеансов для одного пользователя.
В операционной системе Windows Server это можно сделать через настройки служб удаленных рабочих столов. Откройте редактор групповых политик gpedit.msc, перейдите в раздел Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Подключения и включите параметр Ограничить пользователей служб удаленных рабочих столов одним сеансом.
В самой платформе 1С ограничить количество сеансов для пользователя стандартными средствами «из коробки» сложнее, но можно использовать специализированный программный код в модуле управляемого приложения. Рассмотрим пример кода, который проверяет количество активных сеансов текущего пользователя при начале работы системы и предотвращает повторный вход:
Процедура ПриНачалеРаботыСистемы()
ТекущийПользовательИнформационнойБазы = ПользователиИнформационнойБазы.ТекущийПользователь();
ИмяПользователя = ТекущийПользовательИнформационнойБазы.Имя;
АктивныеСеансы = ПолучитьСоединенияИнформационнойБазы();
КоличествоСеансов = 0;
Для Каждого Сеанс Из АктивныеСеансы Цикл
Если Сеанс.Пользователь.Имя = ИмяПользователя Тогда
КоличествоСеансов = КоличествоСеансов + 1;
КонецЕсли;
КонецЦикла;
Если КоличествоСеансов > 1 Тогда
ПоказатьПредупреждение(, "Для вашей учетной записи уже запущен сеанс работы с базой! Повторный вход ограничен.");
Отказ = Истина;
ЗавершитьРаботуСистемы(Ложь);
КонецЕсли;
КонецПроцедуры
Использование подобных проверок позволяет гарантировать, что пользователи не будут дублировать сеансы в базе данных.
Как показывает практика и обсуждения ИТ-специалистов, радикальным и наиболее современным решением проблемы бесконечного ожидания процесса splwow64.exe является отказ от использования 32-битного клиента 1С на 64-битных серверах.
Если архитектура операционной системы сервера х64 и платформа 1С:Предприятие (клиентское приложение) также будет х64, то системе больше не потребуется использовать транслятор печати splwow64.exe для связи с принтерами. Печать будет выполняться напрямую через родные 64-битные системные библиотеки, что полностью исключает зависание сеансов по вине диспетчера печати. При первой возможности выполните обновление клиентских лицензий и установите 64-разрядную версию платформы 1С:Предприятие для всех пользователей терминального сервера.
Мы подробно проанализировали проблему зависания RDP-сессий при работе с 1С и изучили комплекс методов борьбы с этим явлением. Для достижения стопроцентного результата рекомендуется применять описанные методы в комплексе: настроить системный реестр для корректного поведения splwow64.exe, задать жесткие лимиты времени жизни отключенных сессий в групповых политиках Windows Server и ограничить время существования спящих сеансов в параметрах самой базы 1С. Эти действия позволят обеспечить стабильную, бесперебойную работу пользователей и оптимальное использование лицензий 1С.