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

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

Добрый день! Уважаемые читатели и гости одного из крупнейших 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).
  • Вы включаете следующий параметр групповой политики для удаления кэшированных копий перемещаемых профилей при выходе пользователя из системы:

Если посмотреть логи 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.

Популярные Похожие записи:

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

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

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

Байты полезной информации

Столкнулся с такой проблемой, что подключение к удаленному рабочему столу в локальной сети зависает на моменте «настройка удаленного сеанса», подключение может происходит 2, 5, 10 минут, но иногда и сразу. Решение в продолжении.

Дело в том, что в новой версии набора протоколов TCP/IP для Windows 7Server 2008 была реализована функция TCP Receive Window Auto-Tuning — автоматическая настройка окна приема TCP. Теоретически эта функция предназначена для оптимизации пропускной способности и улучшения работы сети, а практически является причиной множества проблем.

Теория
Окно приема TCP используется для ограничения потока данных и для обеспечения возможности контроля потока на принимающей стороне. Окно TCP представляет собой объем данных, который получатель разрешает отправлять за один прием. То есть, чем больше окно, тем лучше работа в сетях с высокой пропускной способностью.
Для TCP/IP в Windows XPServer 2003 максимальный размер окна приема фиксирован и по умолчению составляет 64КБ. В Windows 7Server 2008 оптимальный размер окна приема определяется динамически. Для этого измеряется пропускная способности канала и скорость извлечения приложением данных из окна приема, после чего размер окна адаптируется в соответствии с этими параметрами. Автотюнинг использует масштабирование окна TCP, благодаря чему максимальный размер окна приема составляет 16 МБ.
В идеале при включении автотюнинга передача данных по сети должна стать более эффективной. Однако не всё так просто. Например, приложение не успевает извлекать данные, текущее окно приема заполняется и принимающий узел начинает уменьшать его размер. При заполнении максимального окна приема размер текущего окна уменьшается до 0 байт, после чего передача данных прекратится.

Практика
Как я уже говорил, проблему с автотюнингом очень сложно локализовать. Поэтому, при наличии неопределенных проблем с сетевыми подключениями в первую очередь смотрим настройки TCP. Сделать это можно из командной строки (с повышенными привилегиями) командой:

netsh interface tcp show global

Здесь нас интересует параметр ″Уровень автонастройки окна получения″ (англ. Receive Window Auto-Tuning Level). Он может принимать значения:

• disabled — автотюнинг выключен, используется фиксированное значение размера приемного окна TCP — 64KB;
• higlyrestricted — позволяет размеру приемного окна выходить за пределы значения по умолчанию, очень ограниченно превышая его;
• restricted — допускает более существенный рост размера окна относительно значения по умолчанию;
• normal — по умолчанию. Позволяет менять размер окна в зависимости от различных условий работы;
• experimental — позволяет увеличивать размер окна до очень больших значений. Следует применять очень осторожно.

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

netsh interface tcp set global autotuninglevel=disabled

После изменения настройки компьютер следует перезагрузить.
Проблема с автотюнингом присутствует в операционных системах Windows Vista, Windows 7, Windows Server 2008 и 2008 R2. По Windows 8 и Server 2012 пока данных нет, хотя автотюнинг в них есть и используется.

Если вы когда-нибудь сталкивались с проблемой, что попытка установить RDP соединение до удаленной машины (будь то серверная или клиентская операционная система), занимает довольно продолжительно время, то эта информация может быть полезной.
Такое поведение (длительные задержки при установке RDP соединения), вызваны тем, что клиент удаленного рабочего стола (mstsc) пытается проверить сертификат RDP соединения удаленного сервера, и при отсутствии доверия к этому сертификату, пытается выполнить обновление списка корневых сертификатов, используя вебсайт Windows Update.

Чтобы отключить такое поведение, необходимо в локальной или групповой политике (GPO), действующей на машину, с которой Вы подключаетесь, изменить значение Turn off Automatic Root Certificates Update на Enabled.
Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Settings или (Computer Configuration -> Policies -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings в зависимости от версии ОС)
Найти: Turn off Automatic Root Certificates Update перевести переключатель в Enabled.

После изменения политики, на машине, с которой выполняется подключение, необходимо в командной строке (от имени администратора) выполнить: gpupdate.

После выполнения этих действий время инициирования RDP соединения заметно сокращается.