Услугите за отдалечен работен плот в момента са заети

Въведение

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

Какво означава, когато се появи съобщение "Услугите за отдалечен работен плот в момента са заети"?

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

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

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

Грешката може да се появи на един потребителски акаунт или на множество потребителски акаунти. Ако е налице първият случай, трябва да е възможно да се рестартира сесията. Въпреки това, ако е налице вторият случай, системата може да не позволи на никой потребител да установи връзка.

В допълнение, проблемът може да засегне или една единствена потребителска сесия, или всички потребителски сесии. Важно е да се направи разлика между двата сценария, тъй като решенията, необходими за тяхното разрешаване, са различни.

Microsoft Learn's Ръководство за отстраняване на проблеми с свързаността на RDS сесии осигурява допълнителни проверки за идентифициране на неуспехи в свързването, засягащи хостове на Windows Server.

Какви са причините за тази грешка?

Има няколко компонента на Windows Server, които участват в установяването на RDP сесия. Проблеми с управлението на сесията, със системните ресурси, с услугите на Windows или с процеса на влизане могат да предотвратят установяването на връзката.

Забавени или неотзивчиви RDP сесии

Сесията може да замръзне, докато се свързва, прекъсва, повторно свързва или излиза. След това Windows не успява да завърши сесията или да освободи ресурсите си.

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

Още едно дисконектната сесия нормално е и трябва да бъде нулирано само ако се заключи.

Изчерпване на ресурси и бури при влизане

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

Тези проблеми са особено изразени по време на логон бури, когато стотици потребители установяват Remote Desktop връзки едновременно. Аутентификацията, груповата политика, зареждането на профили и стартирането на приложения генерират значителна натовареност на споделен Remote Desktop Session Host.

Въпреки това, високото използване на ресурси не е изискване за срещане на тази грешка. Някои неуспехи при обработката на сесии се случват дори когато процентите на използване на CPU и памет са ниски.

Изтичане на памет и софтуер на трети страни

Изтичания на памет и обекти на сесия, които не са освободени правилно, могат да повлияят на способността на Windows Server да приема дистанционни връзки.

Този проблем е особено забележим в случаи, когато рестартирането на машината възстановява нормалната функционалност, но грешката се появява отново след няколко часа или дни.

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

Тъй като тези драйвери обикновено не се освобождават, когато съответната системна услуга бъде спряна, разследването на такива хипотези изисква по-подробен подход, отколкото просто спирането на услугата.

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

Груповата политика диктува дистанционен достъп права, свързани с връзките, ограничения на сесиите и други функции на поведението на Remote Desktop Session Host. Неправилните права или конфликти между политиките могат да причинят проблеми с връзката.

Неуспехите на услугата Group Policy Client също могат да нарушат процеса на влизане в Windows.

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

Какво трябва да направите, за да поправите тази грешка?

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

Следната процедура може да се използва за стесняване на проблема, без да се нарушава работата на потребителите.

Стъпка 1: Определете дали проблемът засяга един потребител или сървъра

Изчакайте кратко и след това опитайте отново. Проблемът може да се коригира сам поради моментно натоварване на ресурсите или забавен процес на влизане.

Ако връзката все още не успее, по-широка Отстраняване на проблеми с RDP връзката може да помогне за изключване на проблеми с мрежата, конфигурацията на клиента или свързаността преди да се проучат управлението на сесиите на Windows Server.

Определете обхвата на проблема, ако той продължава:

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

В случая с виртуални машини, имайте предвид, че връзките с конзолата на хипервизора не използват RDP. Ако използвате Hyper-V, трябва да използвате типа Основна сесия, тъй като Разширените сесии използват RDP.

Ако влизането в конзолата не успява, разследвайте проблеми на ниво Windows или операционната система, а не само специфични проблеми с RDS.

Стъпка 2: Проверете ресурсите на Windows Server

След като административният достъп е наличен, проверете използването на CPU, наличната памет, активността на диска и капацитета за съхранение, като използвате Диспечер на задачите или Монитор на производителността.

За бърза проверка на пространството на системния диск, стартирайте PowerShell:

Get-Volume -DriveLetter C

Да се идентифицират процесите, които консумират най-много физическа памет:

Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, Id, WorkingSet64

Търсете необичайно потребление на ресурси, особено по време на удостоверяване или зареждане на профил.

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

Стъпка 3: Идентифицирайте и нулирайте заседнали RDP сесии

Когато конкретен потребител не може да се свърже отново, проверете сесиите на засегнатия сървър.

Отворете повишен команден ред и изпълнете:

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

SESSIONNAME    USERNAME    ID             STATE  
конзола                 Админ             1              Активен  
rdp-tcp#5             Потребител01            3              Активен  
                               Потребител02            4              Изключен  
rdp-tcp                                           65536     Слушане

Ако сесията е потвърдена, че не функционира правилно, нулирайте я, използвайки нейния идентификатор:

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

Администраторите с подходящи разрешения могат също да запитват сесии отдалечено:

След това нулирайте идентифицираната сесия:

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

Не нулирайте всяка прекъсната сесия безразборно. Също така избягвайте насилствено прекратяване на критични Windows процеси като csrss.exe което може да дестабилизира операционната система.

Стъпка 4: Проверете услугите за отдалечен работен плот и журналите на събитията

Ако възстановяването на сесията не реши грешката, проверете услугата Remote Desktop Services.

Стартиране:

Get-Service -Name TermService

Услугата обикновено трябва да докладва за едно Работещо статус. Въпреки това, това само потвърджава, че услугата работи, а не че Windows може успешно да инициализира нови сесии.

След това отворете Event Viewer и прегледайте съответните журнали.

Журнал на Event Viewer	Какво да проучите
Windows Logs > Система	Неуспехи на услугата и системни грешки
Windows Logs > Приложение	Сривове на приложения и грешки в профила
Управление на локални сесии на терминалните услуги > Оперативно	Създаване на сесия, влизане и повторно свързване
Управление на отдалечени връзки на Terminal Services > Оперативен	Обработка на връзки и удостоверяване
Групова политика > Оперативен	Неуспехи при обработка на политики

Последните три дневника се намират под Приложения и услуги Логове > Microsoft > Windows .

Корелирайте събитията с точния момент на неуспешна връзка. Събитие, което се случва близо до провала, може да предостави доказателства, но не установява автоматично причинно-следствена връзка.

Ако множество потребители са засегнати и целевото възстановяване е неуспешно, може да се обмисли контролирано рестартиране на Remote Desktop Services.

Restart-Service -Name 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 средата чрез проследяване на CPU, памет, диск , и едновременно регистрирани сесии.

Наблюдавайте тенденции, а не прагове. Анализът на основната линия е особено важен за отстраняване на проблеми, които възникват по време на пикови часове или се появяват постепенно след рестартиране на сървърите.

Наблюдавайте системата, за да различавате между проблеми с капацитета и неизправности, които все още се появяват, въпреки достатъчните ресурси.

Внимателно конфигурирайте времевите ограничения на сесиите

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

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

Политиките за изтичане на сесии трябва да се основават на бизнес изисквания и не трябва да се използват като решение за основните проблеми със сесиите.

Поддържайте софтуер за Windows и свързани сесии

Имплементирайте поддържани актуализации и корекции за Windows Server за конкретни проблеми.

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

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

Преглед на капацитета и конфигурацията на RDS

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

Помислете за разпределяне на сесиите между множество хостове за по-големи среди, за да избегнете задръствания.

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

Търсите ли по-прост Remote Desktop и Application Delivery?

Отстраняването на проблеми с Remote Desktop Services може да подчертае административните усилия, свързани с поддържането на среди за доставка на приложения за Windows. За организациите, които основно трябва да предоставят на потребителите приложения за Windows или пълни отдалечени работни плотове, прегледът на сложността на съществуващата им инфраструктура може да бъде полезен.

TSplus Remote Access предлага опростен подход за публикуване на Windows приложения за множество потребители и доставка на отдалечен работен плот, с достъп чрез браузър и централизирана администрация. Помага на ИТ екипите да направят приложенията достъпни за отдалечени потребители, без да е необходимо внедряване на цялата сложност на традиционната инфраструктура на Microsoft RDS, като все пак изисква подходяща поддръжка и сигурност на Windows Server.

Заключение

Грешката "Услугите за отдалечен работен плот в момента са заети" изисква повече от рутинен рестарт на сървъра. Идентифицирането на това дали проблемът произтича от заседнала сесия, ограничение на ресурсите или проблем с влизането в Windows позволява на администраторите да изберат най-малко нарушаващото решение.

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