Вопрос или проблема
Я уже несколько недель с перерывами работаю над проблемой, и не могу найти решение.
У нас есть устаревшее настольное приложение MS Access на виртуальной машине Azure, которое мы транслируем пользователям в качестве MS RemoteApp. Они входят в систему через ярлык на рабочем столе (или через RD Web Access, разницы, похоже, нет).
Часто случается, если они закрывают RemoteApp и затем пытаются снова его открыть вскоре после этого, приложение отказывается загружаться. Окно MSTSC просто зависает, и когда я нажимаю кнопку “развернуть”, чтобы увидеть, что происходит на самом деле, я вижу, что пользователь застрял на экране “Добро пожаловать” Windows.
Ничего не помогает, кроме как войти на сервер как администратор и вручную разлогинить пользователя. Единственные процессы, открытые в это время, — это исполняемый файл Access (но я могу убить его вручную, и сеанс все равно зависает) и некоторые процессы Windows (см. скриншот). Кто-нибудь имеет представление, как я могу избежать проблемы с зависшими сеансами?
Запущенные процессы для пользователя, которые застряли на экране приветствия
Сервер — Windows Server 2019 Datacenter со всеми обновлениями, установленными на сегодняшний день.
Проблема **специфически **связана с подключениями сразу после закрытия предыдущего соединения.
Я уже
- Играл с конфигурацией сервера (GPO и другие настройки), безрезультатно
- Развернул дополнительное приложение RemoteApp, которое вручную запускает logoff.exe на сервере (тоже не проходит через экран приветствия)
- Убил mstsc.exe локально
- Гуглил много
- …
но без большого результата… Надеюсь, кто-то здесь сталкивался с той же проблемой.
Установите политику “Выбор обнаружения сети на сервере” на “Выключить постоянное обнаружение сети”.
Политика позволяет вам указать, как протокол удаленного рабочего стола будет пытаться выявлять качество сети (скорость и задержка). Вы можете выбрать отключение Connect Time Detect, постоянного обнаружения сети, или и того и другого.
Если вы отключите Connect Time Detect, протокол удаленного рабочего стола не будет определять качество сети во время подключения и будет предполагать, что весь трафик к этому серверу исходит от низкоскоростного соединения.
Если вы отключите постоянное обнаружение сети, протокол удаленного рабочего стола не будет пытаться адаптировать удаленный пользовательский опыт к изменяющемуся качеству сети.
Политику (GPO) можно найти здесь:
Компьютер > Административные шаблоны > Службы удаленных рабочих столов > Хост сеансов удаленного рабочего стола > Подключения > “Выбор обнаружения сети на сервере”
Если локально, то эта настройка доступна здесь:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Set DWORD "SelectNetworkDetect" to "2"
.
Ответ или решение
Проблема, с которой вы столкнулись, связана с зависанием приложения MS RemoteApp на экране "Добро пожаловать" после повторного подключения, и имеет отношение к специфическим условиям вашего текущего сетапа. Давайте разберёмся в возможных причинах и решениях этой ситуации.
Теоретическая часть (Theory)
Чтобы понять суть проблемы, нужно знать, как работает Remote Desktop Protocol (RDP) и какие процессы происходят при подключении и отключении удаленных сессий. RDP предназначен для передачи данных между клиентским и серверным компьютером, оптимизируя процесс через механизмы, такие как определение качества сети (позволяет реагировать на изменения пропускной способности и задержки).
Экранирование пользователей на "Добро пожаловать" при повторных подключениях может быть вызвано некорректной очисткой предыдущей сессии. Совместное функционирование устаревших приложений, таких как MS Access в виртуализированной среде Azure, и особенностей RemoteApp также вносят свой вклад, затрудняя восстановление сессий.
Примеры (Example)
В вашем случае, при повторном подключении приложение не сумело корректно завершить предыдущие процессы, оставляя после себя "призрака" (остающиеся процессы RemoteApp и mstsc.exe). Таким образом, при следующем подключении система не может корректно восстановить сессию и застревает на начальном экране.
Прокомментированные вами действия, такие как попытка убить процессы вручную или использование logoff.exe не приводят к должным результатам, так как, вероятнее всего, причина кроется в сетевых или GPO-политиках.
Применение (Application)
Рассмотрим несколько шагов, которые могут помочь решить вашу проблему:
-
Отключение постоянного определения сети (Continuous Network Detect):
- Политика "Select network detection on the server" позволяет регулировать, как RDP определяет качество сети. Попробуйте отключить параметр Continuous Network Detect, чтобы RDP не пытался адаптировать опыт пользователей под изменения качества сети.
- Это можно сделать через GPO:
Компьютер > Административные шаблоны > Службы удалённых рабочих столов > Узел сеансов Удалённых рабочих столов > Подключения > "Выбор обнаружения сети для сервера". - Или через реестр: измените параметр
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal ServicesнаDWORD "SelectNetworkDetect" значение "2".
-
Очистка сессий и ресурсов:
- Убедитесь, что конфигурация сервера Windows Server 2019 позволяет автоматически очищать потерпевшие сбой или "зависшие" сессии. Это может потребовать настройки таймера на автоматическое завершение сеансов idle-состояния или неправильных завершений.
- Возможно, понадобится проанализировать журналы событий для поиска неполадок при завершении предыдущих сеансов.
-
Устранение конфликта приложений:
- Возможно, конфликты процессов в приложении MS Access проявляются при вызове через RemoteApp. Рекомендуется создать логи действий приложения и изучить последовательность операций, чтобы выявить критические моменты.
- Обновление драйверов сетевых адаптеров виртуальных машин, а также самого приложения может помочь устранить неисправности.
-
Диагностика сетевых условий:
- Используя инструменты мониторинга, такие как Performance Monitor или сторонние службы мониторинга, можно выявить причины периодических задержек или сбоев в сети, которые могут приводить к сбоям в соединении.
-
Внедрение написания отчетов о сбоях:
- Настройка системы отчетности, которая может включать запись детализированной информации о состоянии процессов до и после повторного подключения, позволит формировать точные данные для анализа проблемы.
Комплексный подход к анализу и устранению подобных проблем потребует времени и точного выполнения диагностических процедур, но в конечном итоге позволит минимизировать интервалы простоя и обеспечить стабильное выполнение удалённых сессий.