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

Добрый день! Уважаемые читатели и гости одного из крупнейших 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 мс) при ожидании ответа транзакции от службы"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнение 18.06.2019

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

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

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