На терминальном сервере висит выход из системы

На терминальном сервере висит выход из системы

терминальный сервер

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами научились отключать тестовый режим windows 10, так что двигаемся дальше. Так уж повелось, что я очень часто стараюсь писать про RDS фермы и терминальные столы, которые являются неотъемлемой частью рабочей инфраструктуры, практически на любом среднем и крупном предприятии. Как следствие, хоть вы и можете организовать отказоустойчивость посредников подключений (брокеров RDS) и сделать нужное вам количество хостов подключений, это не избавит вас от ситуации, что Session Host (отдельный) может выходить из строя или приходить в глючное состояние. Сегодня я как раз и хочу поговорить, об одной такой ситуации с отдельным хостом подключения в RDS ферме, а именно у пользователя при корректном выходе с него, бесконечно долго висит экран с надписью "Выход из системы", как следствие он не может подключиться к другом хосту. Давайте смотреть в чем проблема и как она решается.

Описание проблемы

Есть RDS ферма на основе Windows Server 2012 R2, состоящая из двух посредников подключений (Connection broker) и 15 хостами подключений (Session Host). Ко мне обратился пользователь, который не мог попасть на терминальный стол. Его сессия была активной. Я попытался сбросить терминальную сессию, но эффекта это не дало, у человека висел экран выхода из системы и больше ничего не происходило. Так как брокеры видели, что его сессия еще активна, то они при последующих попытках перекидывали его именно на данный терминальный стол, в результате он не мог работать. Выглядит это вот так.

Висит надпись выход из системы

В данной реализации RDS фермы настроены перемещаемые профили, располагающиеся на сетевом ресурсе. Вот некоторые симптомы ситуации:

  • У вас есть сервер служб удаленных рабочих столов (RDS) на основе Windows Server 2008 R2 SP1 или выше, на котором установлена ​​функция Windows Desktop Search (WDS).
  • Учетные записи пользователей настроены на использование перемещаемых профилей, когда пользователи входят на сервер RDS с помощью протокола удаленного рабочего стола (RDP).
  • Вы включаете следующий параметр групповой политики для удаления кэшированных копий перемещаемых профилей при выходе пользователя из системы:
    Конфигурация компьютера - Административные шаблоны - Система - Профили пользователей - Удалить кэшированные копии перемещаемых профилей
  • Много пользователей входят и выходят с сервера RDS удаленно

Если посмотреть логи Windows, то вы можете обнаружить ряд ошибок с кодом ID 7011, что "Превышение времени ожидания (30000 мс) при ожидании ответа транзакции от службы"

событие 7011

Возможные причины

  • Эта проблема возникает из-за накопления устаревших записей реестра. Следовательно, приложению, использующему Crawl Scope Manager (CSM) для запроса правил области, требуется много времени для перечисления устаревших записей реестра.
  • После выхода из системы файл splwow64.exeпродолжает работу

Устранение проблемы с висящим выходом с терминала

Данная ситуация для меня не нова, я ее еще наблюдал с Windows Server 2008 R2, где все решалось определенным обновлением, но в случае с Windows Server 2012 R2, это пол дела, от нас потребуется по мимо обновлений, внести правки в реестр. Так что начинаем. Первым делом, чтобы количество людей попавших в данную ситуацию не увеличилось, вам необходимо запретить новые подключения к данному хосту. Сделать, это можно из оснастки управления RDS фермой. В данном случае вы переводите хост в режим стока (drain mode).

Запрет новых подключений в RDS

Далее вы пробуете сами попасть на данный хост, где будите ждать когда остальные пользователи закончат свою работу и вы сможете начать исправления глюка с выходом из системы терминальной сессии людей. Далее первым этапом, вы должны установить все доступные исправления безопасности Windows. Напоминаю, что делается это в панели управления или в параметрах Windows, все зависит от версии системы. так, это выглядит в системах до Windows Server 2016

Поиск обновлений в Windows Server 2012 r2

И вот так уже в системах после Windows Server 2016

Установка обновлений в Windows Server 2019

После того, как вы произвели установку всех обновлений перезагрузите ваш сервер. Кстати, когда я через PowerShell решил посмотреть ID и статусы сессий на терминальном столе, то увидел необычный для себя статус "Down", это как раз и были люди, у кого висел выход из системы.

Статус doww на rds ферме

Еще одной из рекомендаций в данной ситуации, это отключение службы поиска Windows. Напоминаю, что в Windows Server 2012 R2 и выше, данная служба устанавливается, как компонент, если она вам не нужна, то удалите его.

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

Одним из сценариев, который соответствует этому критерию, является печать из 32-разрядного приложения на 64-разрядном узле сеансов удаленных рабочих столов. Это действие печати вызовет splwow64.exe, 32 и 64-разрядный процесс thunking для спулера. Splwow64.exe имеет 3-минутный тайм-аут для предотвращения повторного запуска процесса во время интенсивной печати, поэтому он не завершается сразу после завершения печати. Это может привести к тому, что удаленный сеанс будет казаться "зависшим".

Чтобы это исправить я вам советую создать ключ реестра. Для этого открываем ветку:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Terminal Server\Sysprocs

Создаем новую запись REG_DWORD с именем splwow64.exe и значением 0.

Висит выход из системы-02

Таким же образом я вам советую добавить сюда же ключ REG_DWORD с именем wrsa.exe и значением 0 (https://en.wikipedia.org/wiki/Winsock)

Висит выход из системы-03

Еще я вам советую слегка увеличить значение одного параметра в реестре WaitToKillServiceTimeout. WaitToKillServiceTimeout - это параметр отвечающий за, то чтобы система закрыла все фоновые приложения. Windows обычно ждет 5 секунд, чтобы фоновые службы очистились и закрылись, когда вы делаете выход из системы или выключаете компьютер. Некоторые приложения могут изменить это значение при установке, предоставляя своим фоновым службам дополнительное время для очистки. Windows принудительно закрывает фоновые службы после этого периода времени. Это значение определяет, сколько секунд Windows ожидает, прежде чем сделать это. Windows автоматически выключится, если все службы будут успешно закрыты до истечения таймера. Я не советую ставить данное значение ниже 2-х секунд, это 2000. В нашей ситуации, когда у вас бесконечно долго висит надпись выход из системы, я советую выставлять WaitToKillServiceTimeout на 15-20 секунд, это значения 15000 или 20000.

Сделать это можно по пути:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

WaitToKillServiceTimeout

И выставите у ключа WaitToKillServiceTimeout нужное значение. Далее желательно перезагрузить терминал и проверить есть ли проблемы с выходом из системы.

Как выкинуть застрявшую сессию, если пока сервер перезагружать нельзя

Выше я уже приводил ссылку на то, как разлогинивать зависшую сессию на терминалах, там мы использовали утилиты rwinsta, logoff или командлеты PowerShell, но к сожалению они не всегда работают. Ниже я покажу, как можно еще попробовать сбросить сессию пользователя, на момент когда у него происходит выход из системы.

Что мы делаем, воспользуемся утилитой qwinsta или любым ее аналогом, коих много. Для начала нужно выяснить ID сеанса у нужного пользователя, для этого введите:

qwinsta /server:имя сервера или qwinsta (Локально)

В моем примере, есть пользователь barboskin.g и его ID сессии 109.

Висит выход из системы-05

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

taskkill /FI "SESSION eq 109" /F (eq это номер ID сессии, который мы получили ранее)

Кстати посмотреть текущие процессы у данного сеанса, можно командой:

tasklist | findstr RDP-Tcp#105

Висит выход из системы-06

Еще после выполнения команды taskkill, у вас в списке пользователей может остаться висеть пользователь с именем (4), просто убейте его из диспетчера задач, должно получиться. Так же вы можете использовать удобную утилиту Process Explorer. зная ID сессии, вы так же можете попытаться завершить нужные вам процессы.

Еще вам советую провести диагностику целостности системных файлов, через утилиту:

sfc /scannow

Восстановление системных файлов Windows-2

После чего, еще выполнить:

Dism /online /cleanup-image /restorehealth

Дополнение 18.06.2019

Так же еще опытным путем было выяснено, что данная проблема можете возникать, из-за:

  • Старой версии VMware Tools, советую установить самую последнюю
  • Из-за типа сетевого интерфейса, на сбойной виртуальной машине был выставлен E100E, а не VMXNET3
  • Так же был удален TDI vShield Endpoint драйвер
  • Еще разбирая логи системы, я обнаружил, что перед тем, как на сервере начинались проблемы, сыпались ошибки с кодом ID 372, ID 600, ID 601, в таких случаях, это были отголоски старых драйверов, которые были заменены на EasyPrint чисткой спулера через задания, на постоянной основе, так как было много зависших заданий.

Диспетчеру печати не удалось импортировать драйвер принтера, скачанный из \\сервер\print$\x64\PCC\oemsetup.inf_amd64_5198ba014245f0a7.cab, в хранилище драйверов для драйвера Kyocera Classic Universaldriver PCL6. Код ошибки: 80070002. Такое возможно при наличии проблем с драйвером или цифровой подписью драйвера.

ID 600

Диспетчеру печати не удалось скачать и импортировать драйвер принтера из \\сервер в хранилище драйверов для драйвера Kyocera Classic Universaldriver PCL6. Код ошибки: 80070002.

ID 601

На этом у меня все, надеюсь, что ваши RDSH хосты стали нормально работать. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

2 Responses to На терминальном сервере висит выход из системы

  1. Ильдар:

    Иван спасибо за статью.
    У нас реальная проблема с этим, ферма из 3 серверов, в пике бывает до 150-200 подключений. Проблема именно с одним хостом, раз в неделю он просто начинает глючить, новые сессии создаются, но в каком то зависшем состоянии,у пользователей висит логон. Помогает только перезагрузка сервера, причем жесткая ( с оснастки кластера), просто так он не перезагружается
    Куча драйверов установлено, и атоловские тоже. Подскажите пожалуйста с чего начать анализ? Как диагностировать? Или проще новый хост поднять и заменить этот? (Ферма досталась по наследству)

  2. Иван Семин:

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *