Службы удаленного рабочего стола в настоящее время заняты

Введение

Когда Windows Server отказывает в новых подключениях к Remote Desktop, важно определить источник сбоя перед перезапуском служб или всего сервера. Проблема затрагивает одного пользователя или несколько сеансов? Эта статья проводит ИТ-администраторов через возможные причины, практические команды для устранения неполадок и процедуры восстановления, от начальных проверок до более сложной диагностики и мер профилактики.

Что означает сообщение "Службы удаленных рабочих столов в настоящее время заняты"?

Ошибка возникает, когда Windows не может выполнить запрашиваемую функцию или действие протокола удаленного рабочего стола (RDP). Обычно сообщение об ошибке, которое появляется, гласит:

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

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

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

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

Microsoft Learn's Руководство по устранению неполадок подключения к сеансу RDS предоставляет дополнительные проверки для выявления сбоев соединения, влияющих на хосты Windows Server.

Каковы причины этой ошибки?

Существует несколько компонентов Windows Server, которые участвуют в установлении RDP-сессии. Проблемы с управлением сессией, с системными ресурсами, с службами Windows или с процессом входа могут помешать установлению соединения.

Зависшие или неотвечающие RDP-сессии

Сессия может зависнуть при подключении, отключении, повторном подключении или выходе из системы. Затем Windows не может завершить сессию или освободить свои ресурсы.

Администраторы могут найти сеансы, которые отказываются переподключаться или выходить. Проблема может возникнуть только в одном сеансе, даже если другие работают правильно.

Тем не менее, отключенная сессия нормально и должно быть сброшено только в случае зависания.

Исчерпание ресурсов и штурм входа

Недостаточные ресурсы могут задержать или предотвратить инициализацию сеанса. Наиболее распространенные проблемы - это насыщение ЦП, нехватка памяти, чрезмерная активность диска и медленная загрузка профиля.

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

Однако высокая загрузка ресурсов не является обязательным условием для возникновения этой ошибки. Некоторые сбои в обработке сеансов происходят даже при низких показателях использования ЦП и памяти.

Утечки памяти и стороннее программное обеспечение

Утечки памяти и объекты сеансов, которые не освобождаются должным образом, могут ухудшить способность Windows Server принимать удаленные подключения.

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

Применение стороннего программного обеспечения, которое каким-либо образом работает с сессиями Windows, также может быть причиной. Это включает в себя агенты защиты конечных точек, фильтры безопасности или аналогичное программное обеспечение, которое может мешать сессиям Windows.

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

Проблемы с групповыми политиками и профилями пользователей

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

Сбои службы клиента групповой политики также могут мешать процессу входа в Windows.

В то же время Windows не может завершить сеанс, если что-то идет не так с профилем пользователя. В этом случае администраторам следует сосредоточиться на службе профилей пользователей, проверить, доступно ли хранилище профиля пользователя, и рассмотреть возможность использования FSLogix или других инструментов для управления профилями пользователей, если длительные сеансы входа совпадают с проблемами подключения.

Что вам нужно сделать, чтобы исправить эту ошибку?

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

Следующая процедура может быть использована для уточнения проблемы без нарушения работы пользователей.

Шаг 1: Определите, затрагивает ли проблема одного пользователя или сервер

Подождите немного и попробуйте снова. Проблема может решиться сама собой из-за временной конкуренции за ресурсы или задержки в процессе входа.

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

Определите масштаб проблемы, если она сохраняется:

• Может ли другой пользователь успешно установить соединение?
• Существуют ли действующие RDP-сессии?
• Случаются ли сбои до или после успешной аутентификации?
• Проблема возникла до или после обновления Windows или изменения конфигурации?
• Может ли администратор войти локально, используя консоль сервера?

В случае виртуальных машин учитывайте, что подключения к консоли гипервизора не используют RDP. Если вы используете Hyper-V, вы должны использовать тип сеанса Basic, потому что Расширенные сеансы используют RDP.

Если входы в консоль не удаются, исследуйте проблемы уровня Windows или операционной системы, а не только проблемы, специфичные для RDS.

Шаг 2: Проверьте ресурсы Windows Server

Как только будет доступен административный доступ, проверьте использование ЦП, доступную память, активность диска и емкость хранения с помощью Диспетчера задач или Монитора производительности.

Для быстрого проверки пространства на системном диске выполните PowerShell:

Get-Volume -DriveLetter C

Чтобы определить процессы, потребляющие больше всего физической памяти:

Получить-Процесс | Сортировать-Объект РабочийНабор64 -ПоУбыванию | Выбрать-Объект -Первый 10 Имя, Ид, РабочийНабор64

Ищите необычное потребление ресурсов, особенно во время аутентификации или загрузки профиля.

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

Шаг 3: Определите и сбросьте зависшие RDP-сессии

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

Откройте командную строку с повышенными привилегиями и выполните:

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

SESSIONNAME    USERNAME    ID             STATE  
консоль                 Admin             1              Активен  
rdp-tcp#5             User01            3              Активен  
                               User02            4              Отключен  
rdp-tcp                                           65536     Прослушивание  

Если сессия подтверждена как неисправная, сбросьте её, используя её ID:

Замените 4 на фактический идентификатор сеанса.

Администраторы с соответствующими правами также могут удаленно запрашивать сеансы:

Затем сбросьте идентифицированную сессию:

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

Не сбрасывайте каждую отключенную сессию без разбора. Также избегайте принудительного завершения критически важных процессов Windows, таких как csrss.exe , что может дестабилизировать операционную систему.

Шаг 4: Проверьте службы удаленного рабочего стола и журналы событий

Если восстановление сеанса не устраняет ошибку, проверьте службу Удаленных рабочих столов.

Запуск:

Get-Service -Name TermService

Служба обычно должна сообщать о Запуск статус. Однако это только подтверждает, что служба работает, а не то, что Windows может успешно инициализировать новые сеансы.

Далее откройте Просмотр событий и проверьте соответствующие журналы.

Журнал просмотра событий	Что исследовать
Журналы Windows > Система	Сбой сервисов и системные ошибки
Журналы Windows > Приложение	Сбой приложения и ошибки профиля
УправлениеСессиямиЛокальныхСлужб > Оперативный	Создание сеанса, вход в систему и повторное подключение
Управление удаленными подключениями Terminal Services > Оперативный	Обработка соединений и аутентификация
Групповая политика > Операционная	Сбои обработки политики

Последние три журнала находятся в разделе Журналы приложений и служб > Microsoft > Windows .

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

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

Перезапустить-Службу -Имя TermService

Эта операция может повлиять на активные соединения и может быть ограничена зависимостями сервиса. Проверьте конфигурацию сервиса и операционные последствия перед ее выполнением.

На производственных хостах RDS предпочтительнее запланированное окно обслуживания, чем перезапуск служб во время работы пользователей.

Шаг 5: Проверьте групповую политику и ограничения подключения

Если ошибка началась после изменения конфигурации, проверьте настройки групповой политики, примененные к затронутому серверу.

Сгенерировать отчет:

Откройте отчет и просмотрите политики в разделе:

Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленного рабочего стола > Хост сеансов удаленного рабочего стола > Подключения

Обратите особое внимание на политики, контролирующие максимальное количество подключений, ограничения на одно сеанс и разрешение на удаленное подключение.

Также проверьте назначения прав пользователя, регулирующие вход через службы удаленного рабочего стола.

Если недавнее изменение политики совпадает с ошибкой, исследуйте его влияние через контролируемое тестирование. Избегайте отключения политик безопасности, не установив, что они способствуют сбою.

Шаг 6: Проверьте лицензирование RDS и режим дренажа

Некоторые сбои соединения происходят из-за конфигурации развертывания RDS, а не из-за неисправных сеансов.

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

Также проверьте, отклоняет ли Хост сеанса намеренно новые подключения:

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

Когда это уместно, новые входы могут быть повторно включены с помощью:

Не отменяйте режим обратного слива, не подтвердив, почему он был активирован.

Проблемы с лицензированием, ограничения на подключения и режим разряда не обязательно приводят к точному сообщению "Службы удаленных рабочих столов в настоящее время заняты". Эти проверки наиболее полезны, когда новые подключения не удаются, но существующие сеансы остаются работоспособными.

Шаг 7: Исследуйте профили пользователей и стороннее программное обеспечение

Если ошибка сохраняется, проверьте компоненты, участвующие в инициализации сеанса.

Для сбоев, специфичных для пользователя, сначала определите, может ли затронутая учетная запись успешно загрузить свой профиль. Обратите внимание на события службы профилей пользователей, доступность хранения профиля и задержки в аутентификации.

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

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

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

Шаг 8: Перезагрузите Windows Server, если это необходимо

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

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

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

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

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

Как действовать, если ошибки занятости RDS повторяются?

Когда ошибка повторяется, акцент смещается с восстановления доступа к сети на определение причин этого сбоя.

Таблица ниже служит полезным руководством для устранения неполадок:

Наблюдаемый симптом	Приоритет расследования
Один пользователь не может повторно подключиться	Зависшая сессия или профиль пользователя
Несколько пользователей не могут подключиться	Состояние службы, ресурсы, обработка сеансов
Ошибка при утреннем входе	Одновременные входы, загрузка профиля, хранилище
Перезагрузка временно решает ошибку	Утечки, связанные с памятью или сессией
Ошибка после обновления программного обеспечения безопасности	Взаимодействие с программным обеспечением третьих сторон
Ошибка следует изменениям групповой политики	Обработка политик и разрешения на вход
Ошибка входа в консоль также происходит	Широкие проблемы с входом в Windows или системой
Существующие сеансы работают, но новые пользователи не могут подключиться.	Ограничения подключения, режим дренажа, лицензирование

Эти шаблоны указывают на приоритеты для расследования, а не на окончательные диагнозы.

Соберите диагностические данные перед перезагрузкой

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

Microsoft предоставляет утилиту TroubleShootingScript (TSS) для сбора диагностических трасс.

В зависимости от сценария администраторы могут захватывать трассировки клиента RDP:

.\TSS.ps1 -Сценарий UEX_RDSCli

И серверные трассировки:

.\TSS.ps1 -Сценарий UEX_RDSSrv

Используйте текущую документацию Microsoft TSS, чтобы подтвердить поддерживаемые сценарии, предварительные условия и процедуры выполнения.

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

В развертываниях с несколькими серверами включите компоненты RD Connection Broker и RD Gateway в расследование, когда путь подключения включает эти службы.

Как вы можете предотвратить эти ошибки?

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

Мониторинг ресурсов сервера и активности сеансов

Мониторинг среды RDS с помощью отслеживание ЦП, памяти, диска , и одновременно зарегистрированные сеансы.

Смотрите на тренды, а не на пороги. Базовый анализ особенно важен для устранения проблем, которые возникают в часы пик или появляются постепенно после перезагрузки серверов.

Мониторьте систему, чтобы различать проблемы с емкостью и сбои, которые все еще происходят, несмотря на достаточные ресурсы.

Тщательно настраивайте время ожидания сеанса

Просмотрите политики, регулирующие отключенные и неактивные сеансы. Microsoft Learn объясняет, как различать непредвиденные блокировки сессий и отключения и изучить политики тайм-аута сессии, ответственные за эти поведения.

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

Политики тайм-аута сессии должны основываться на бизнес-требованиях и не должны использоваться как средство для устранения основных утечек сессий.

Поддержка программного обеспечения, связанного с Windows и сессиями

Реализуйте поддерживаемые обновления и исправления Windows Server для конкретных проблем.

Убедитесь, что агенты защиты конечных точек, компоненты управления профилем, компоненты виртуализации и приложения, интегрированные в сеанс, совместимы с операционной системой.

Проверьте обновления в предрелизной среде, особенно если в процессе входа в Windows или сеанса участвуют несколько сторонних компонентов.

Обзор емкости и конфигурации RDS

Размер хостов удаленного рабочего стола в соответствии с реалистичными одновременными нагрузками, с учетом пиковых часов для входа и запуска программ.

Рассмотрите возможность распределения сеансов между несколькими хостами для больших сред, чтобы избежать перегрузки.

Аудит групповой политики, ограничений подключения, конфигурации лицензий и практик обслуживания регулярно для выявления и устранения потенциальных причин сбоев подключения.

Ищете более простой удаленный рабочий стол и доставку приложений?

Устранение неполадок в службах удаленного рабочего стола может подчеркнуть административные усилия, связанные с поддержанием среды доставки приложений Windows. Для организаций, которые в первую очередь нуждаются в предоставлении пользователям приложений Windows или полных удаленных рабочих столов, может быть целесообразно пересмотреть сложность их существующей инфраструктуры.

TSplus Удаленный доступ предлагает упрощенный подход к публикации многопользовательских приложений Windows и доставке удаленного рабочего стола с доступом через браузер и централизованным управлением. Это помогает ИТ-командам делать приложения доступными для удаленных пользователей без развертывания всей сложности традиционной инфраструктуры Microsoft RDS, при этом все еще требуя надлежащего обслуживания и безопасности Windows Server.

Заключение

Ошибка "Службы удаленных рабочих столов в настоящее время заняты" требует больше, чем просто обычная перезагрузка сервера. Определение того, возникает ли сбой из-за зависшей сессии, ограничения ресурсов или проблемы с входом в Windows, позволяет администраторам выбрать наименее разрушительное решение.

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