Usługi pulpitu zdalnego są obecnie zajęte

Wprowadzenie

Kiedy system Windows Server odmawia nowych połączeń zdalnego pulpitu, zidentyfikowanie źródła awarii jest kluczowe przed ponownym uruchomieniem usług lub całego serwera. Czy problem dotyczy jednego użytkownika, czy wielu sesji? Ten artykuł prowadzi administratorów IT przez możliwe przyczyny, praktyczne polecenia rozwiązywania problemów oraz procedury odzyskiwania, od wstępnych kontroli po bardziej zaawansowaną diagnostykę i środki zapobiegawcze.

Co oznacza, gdy pojawia się komunikat "Usługi pulpitu zdalnego są obecnie zajęte"?

Błąd występuje, gdy system Windows nie może wykonać żądanej funkcji lub akcji protokołu pulpitu zdalnego (RDP). Zazwyczaj komunikat o błędzie, który się pojawia, stwierdza:

Zadanie, które próbujesz wykonać, nie może zostać zrealizowane, ponieważ Usługi Pulpitu Zdalnego są obecnie zajęte. Proszę spróbować ponownie za kilka minut. Inni użytkownicy powinni nadal móc się zalogować.

Chociaż komunikat o błędzie sugeruje, że system nie może dodać kolejnej sesji i że zdalny pulpit osiągnął maksymalną pojemność, może to nie być prawdą.

Błąd może wystąpić na pojedynczym koncie użytkownika lub na wielu kontach użytkowników. Jeśli ma to miejsce w pierwszym przypadku, powinno być możliwe ponowne uruchomienie sesji. Jednak jeśli ma to miejsce w drugim przypadku, system może nie pozwolić żadnemu użytkownikowi na nawiązanie połączenia.

Dodatkowo problem może dotyczyć pojedynczej sesji użytkownika lub wszystkich sesji użytkowników. Ważne jest, aby odróżnić te dwa scenariusze, ponieważ wymagane rozwiązania do ich rozwiązania różnią się.

Microsoft Learn's Wskazówki dotyczące rozwiązywania problemów z łącznością sesji RDS zapewnia dodatkowe kontrole w celu identyfikacji awarii połączenia wpływających na hosty Windows Server.

Jakie są przyczyny tego błędu?

Istnieje kilka komponentów systemu Windows Server, które są zaangażowane w nawiązywanie sesji RDP. Problemy z zarządzaniem sesją, z zasobami systemowymi, z usługami systemu Windows lub z procesem logowania mogą uniemożliwić nawiązanie połączenia.

Zablokowane lub nieodpowiadające sesje RDP

Sesja może się zawiesić podczas łączenia, rozłączania, ponownego łączenia lub wylogowywania. Wtedy system Windows nie jest w stanie zakończyć sesji ani zwolnić jej zasobów.

Administratorzy mogą znaleźć sesje, które odmawiają ponownego połączenia lub wylogowania. Problem może wystąpić tylko w jednej sesji, nawet jeśli inne działają poprawnie.

Jeszcze a rozłączona sesja jest normalne i powinno być zresetowane tylko w przypadku zablokowania.

Wyczerpanie zasobów i burze logowania

Niewystarczające zasoby mogą opóźnić lub uniemożliwić inicjalizację sesji. Najczęstsze problemy to nasycenie CPU, niedobory pamięci, nadmierna aktywność dysku i wolne ładowanie profilu.

Takie problemy są szczególnie widoczne podczas burz logowania, gdy setki użytkowników jednocześnie nawiązują połączenia z pulpitem zdalnym. Uwierzytelnianie, zasady grupy, ładowanie profilu i uruchamianie aplikacji generują znaczne obciążenie na wspólnym hoście sesji pulpitu zdalnego.

Jednak wysokie wykorzystanie zasobów nie jest wymaganiem do napotkania tego błędu. Niektóre awarie przetwarzania sesji występują nawet przy niskim poziomie wykorzystania CPU i pamięci.

Wycieki pamięci i oprogramowanie firm trzecich

Wycieki pamięci i obiekty sesji, które nie są prawidłowo zwalniane, mogą osłabić zdolność serwera Windows do akceptowania połączeń zdalnych.

Problem ten jest szczególnie zauważalny w przypadkach, gdy ponowne uruchomienie maszyny przywraca normalną funkcjonalność, ale błąd powraca po kilku godzinach lub dniach.

Zastosowanie oprogramowania firm trzecich, które w jakiś sposób współpracuje z sesjami systemu Windows, może być również przyczyną. Obejmuje to agentów ochrony punktów końcowych, filtry zabezpieczeń lub podobne oprogramowanie, które może zakłócać sesje systemu Windows.

Ponieważ te sterowniki zazwyczaj nie są odładowywane, gdy odpowiednia usługa systemowa jest zatrzymywana, badanie takich hipotez wymaga dokładniejszego podejścia niż tylko zatrzymanie usługi.

Problemy z zasadami grupy i profilem użytkownika

Polityka grupowa dyktuje remote access uprawnienia dotyczące połączeń, ograniczenia sesji i inne cechy zachowania Host Session Pulpitu Zdalnego. Niewłaściwe uprawnienia lub konflikty między politykami mogą powodować problemy z połączeniem.

Awaria usługi klienta zasad grupy może również zakłócać proces logowania do systemu Windows.

Jednocześnie system Windows nie jest w stanie zakończyć sesji, jeśli coś pójdzie nie tak z profilem użytkownika. W takim przypadku administratorzy powinni skupić się na Usłudze Profilu Użytkownika, sprawdzić, czy przechowywanie profilu użytkownika jest dostępne, oraz rozważyć FSLogix lub inne narzędzia do zarządzania profilami użytkowników, jeśli długie sesje logowania pokrywają się z problemami z połączeniem.

Co musisz zrobić, aby naprawić ten błąd?

Działania związane z rozwiązywaniem problemów powinny być podejmowane od ogólnych do szczegółowych i przechodzić od testów niezakłócających do ukierunkowanego odzyskiwania sesji oraz ponownego uruchamiania usług lub serwerów tylko w razie konieczności.

Następująca procedura może być użyta do zawężenia problemu bez zakłócania pracy użytkowników.

Krok 1: Określ, czy problem dotyczy jednego użytkownika, czy serwera

Poczekaj chwilę, a następnie spróbuj ponownie. Problem może się rozwiązać samodzielnie z powodu chwilowego przeciążenia zasobów lub opóźnionego procesu logowania.

Jeśli połączenie nadal nie działa, szersze Rozwiązywanie problemów z połączeniem RDP może pomóc wykluczyć problemy z siecią, konfiguracją klienta lub łącznością przed zbadaniem zarządzania sesjami Windows Server.

Określ zakres problemu, jeśli on się utrzymuje:

• Czy inny użytkownik może pomyślnie nawiązać połączenie?
• Czy istniejące sesje RDP są operacyjne?
• Czy awarie występują przed czy po pomyślnej autoryzacji?
• Czy problem pojawił się przed czy po aktualizacji systemu Windows lub zmianie konfiguracji?
• Czy administrator może zalogować się lokalnie za pomocą konsoli serwera?

W przypadku maszyn wirtualnych należy pamiętać, że połączenia konsoli hypervisora nie korzystają z RDP. Jeśli używasz Hyper-V, musisz użyć typu sesji podstawowej, ponieważ sesje rozszerzone korzystają z RDP.

Jeśli logowania konsolowe nie powiodą się, zbadaj problemy z logowaniem na poziomie systemu Windows lub problemy z systemem operacyjnym, a nie tylko problemy specyficzne dla RDS.

Krok 2: Sprawdź zasoby serwera Windows

Gdy dostęp administracyjny jest dostępny, sprawdź wykorzystanie CPU, dostępna pamięć, aktywność dysku i pojemność pamięci masowej za pomocą Menedżera zadań lub Monitora wydajności.

Aby szybko sprawdzić przestrzeń na dysku systemowym, uruchom PowerShell:

Get-Volume -DriveLetter C

Aby zidentyfikować procesy zużywające najwięcej pamięci fizycznej:

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

Szukaj nietypowego zużycia zasobów, szczególnie podczas uwierzytelniania lub ładowania profilu.

Pojedynczy zrzut wydajności może nie ujawniać wycieku pamięci. Jeśli zużycie zasobów wydaje się normalne, kontynuuj diagnostykę sesji i zbieraj dane wydajnościowe w czasie, jeśli błąd się powtórzy.

Krok 3: Zidentyfikuj i zresetuj zablokowane sesje RDP

Gdy konkretny użytkownik nie może ponownie połączyć się, sprawdź sesje na dotkniętym serwerze.

Otwórz wiersz polecenia z uprawnieniami administratora i uruchom:

Polecenie wyświetla identyfikatory sesji, nazwy użytkowników i stany połączenia. Typowy wynik może wyglądać następująco:

SESSIONNAME    USERNAME    ID             STATE  
console                 Admin             1              Aktywny  
rdp-tcp#5             User01            3              Aktywny  
                               User02            4              Rozłączony  
rdp-tcp                                           65536     Nasłuchuj  

Jeśli sesja została potwierdzona jako nieprawidłowa, zresetuj ją, używając jej identyfikatora:

Zastąp 4 rzeczywistym identyfikatorem sesji.

Administratorzy z odpowiednimi uprawnieniami mogą również zdalnie zapytywać o sesje:

Następnie zresetuj zidentyfikowaną sesję:

Uwaga Resetowanie sesji kończy jej aplikacje i może spowodować utratę niezapisanej pracy. Zweryfikuj tożsamość sesji i powiadom użytkownika, gdy tylko będzie to możliwe.

Nie resetuj każdej rozłączonej sesji bez zastanowienia. Unikaj również wymuszania zakończenia krytycznych procesów systemu Windows, takich jak csrss.exe , co może destabilizować system operacyjny.

Krok 4: Sprawdź usługi pulpitu zdalnego i dzienniki zdarzeń

Jeśli odzyskiwanie sesji nie rozwiązuje błędu, sprawdź usługę Zdalne Pulpity.

Uruchom:

Get-Service -Name TermService

Usługa powinna normalnie zgłaszać a Uruchamianie status. Jednak to tylko potwierdza, że usługa działa, a nie że Windows może pomyślnie zainicjować nowe sesje.

Następnie otwórz Podgląd zdarzeń i sprawdź odpowiednie dzienniki.

Dziennik Podglądu Zdarzeń	Co badać
Dzienniki systemu Windows > System	Awaria usług i błędy systemu
Dzienniki systemu Windows > Aplikacja	Awaria aplikacji i błędy profilu
TerminalServices-LocalSessionManager > Operacyjny	Tworzenie sesji, logowanie i ponowne połączenie
Zarządzanie połączeniami zdalnymi Terminal Services > Operacyjne	Zarządzanie połączeniami i uwierzytelnianiem
GrupaPolityki > Operacyjny	Niepowodzenia w przetwarzaniu polityki

Ostatnie trzy dzienniki znajdują się pod Dzienniki aplikacji i usług > Microsoft > Windows .

Skoreluj zdarzenia z dokładnym czasem nieudanej próby połączenia. Zdarzenie występujące w pobliżu awarii może dostarczyć dowodów, ale nie ustala automatycznie związku przyczynowego.

Jeśli wielu użytkowników jest dotkniętych, a docelowe odzyskiwanie jest nieudane, można rozważyć kontrolne ponowne uruchomienie Usług Pulpitu Zdalnego.

Restart-Service -Name TermService

Ta operacja może wpłynąć na aktywne połączenia i może być ograniczona przez zależności usług. Sprawdź konfigurację usługi i konsekwencje operacyjne przed podjęciem próby.

Na produkcyjnych hostach RDS lepiej jest zaplanować okno konserwacyjne niż ponownie uruchamiać usługi, gdy użytkownicy pracują.

Krok 5: Przejrzyj zasady grupowe i ograniczenia połączeń

Jeśli błąd rozpoczął się po zmianie konfiguracji, sprawdź ustawienia zasad grupy zastosowane do dotkniętego serwera.

Generuj raport:

Otwórz raport i przeglądaj zasady w sekcji:

Konfiguracja komputera > Szablony administracyjne > Komponenty systemu Windows > Usługi pulpitu zdalnego > Host sesji pulpitu zdalnego > Połączenia

Zwróć szczególną uwagę na zasady kontrolujące maksymalną liczbę połączeń, ograniczenia dotyczące pojedynczej sesji oraz zezwolenie na zdalne połączenie.

Również zweryfikuj przypisania praw użytkowników regulujących logowanie przez Usługi Pulpitu Zdalnego.

Jeśli niedawna zmiana polityki zbiegła się z błędem, zbadaj jej wpływ poprzez kontrolowane testy. Unikaj wyłączania polityk bezpieczeństwa bez ustalenia, że przyczyniają się do awarii.

Krok 6: Zweryfikuj licencjonowanie RDS i tryb odprowadzania

Niektóre awarie połączenia pochodzą z konfiguracji wdrożenia RDS, a nie z uszkodzonych sesji.

Dla wdrożeń hosta sesji pulpitu zdalnego dla wielu użytkowników, zweryfikuj tryb licencjonowania i skonfigurowany serwer licencji.

Sprawdź również, czy Host Sesji celowo odrzuca nowe połączenia:

Jeśli logowanie nowych użytkowników jest wyłączone, ustal, czy serwer został umieszczony w trybie drenażu w celu konserwacji.

Gdy to konieczne, nowe logowania mogą być ponownie włączone za pomocą:

Nie odwracaj trybu drenażu bez potwierdzenia, dlaczego został aktywowany.

Problemy z licencjonowaniem, limity połączeń i tryb oszczędzania energii niekoniecznie generują dokładny komunikat "Usługi pulpitu zdalnego są obecnie zajęte". Te kontrole są najbardziej przydatne, gdy nowe połączenia nie udają się, ale istniejące sesje pozostają operacyjne.

Krok 7: Zbadaj profile użytkowników i oprogramowanie firm trzecich

Jeśli błąd będzie się powtarzał, zbadaj komponenty zaangażowane w inicjowanie sesji.

Aby zidentyfikować problemy specyficzne dla użytkownika, najpierw ustal, czy dotknięte konto może pomyślnie załadować swój profil. Sprawdź zdarzenia usługi profilu użytkownika, dostępność przechowywania profilu oraz opóźnienia w uwierzytelnianiu.

W kontekście FSLogix lub dysków profili użytkowników, rozważ dostępność kontenerów profili, awarie montowania i problemy z wydajnością przechowywania.

Skup się na niedawno zainstalowanym lub zaktualizowanym oprogramowaniu, które współdziała z sesjami systemu Windows, w przypadku systemowych, powtarzających się awarii.

Agenci zabezpieczeń, produkty ochrony punktów końcowych i filtry na poziomie systemu mogą powodować błędy w przetwarzaniu sesji. Wszelkie testy izolacyjne powinny być przeprowadzane zgodnie z zaleceniami dostawcy i procedurami kontroli zmian.

Krok 8: Uruchom ponownie serwer Windows, jeśli to konieczne

Jeśli docelowe rozwiązywanie problemów nie rozwiązuje problemu, ponowne uruchomienie serwera może przywrócić łączność RDP.

Przed ponownym uruchomieniem upewnij się, że rozumiesz wpływ na aktualnie nawiązane sesje i hostowane aplikacje. Jeśli to możliwe, w przypadku wdrożenia RDS z wieloma hostami, odłącz hosta i przekieruj nowe połączenia do innego hosta.

Po ponownym uruchomieniu potwierdź, że usługi pulpitu zdalnego działają poprawnie, użytkownicy mogą się łączyć, a w Podglądzie zdarzeń nie są generowane żadne nowe błędy.

Restart potwierdza, że sytuacja powodująca bezpośredni problem została rozwiązana, ale nie potwierdza, że przyczyna źródłowa została usunięta.

Jeśli błąd pojawi się ponownie po restarcie, zachowaj dowody do dalszego dochodzenia i poszukaj wzorców nadmiernego zużycia zasobów, awarii w przetwarzaniu poszczególnych sesji oraz zakłóceń spowodowanych przez oprogramowanie firm trzecich.

Jak powinieneś postępować, jeśli błędy zajętości RDS się powtarzają?

Gdy błąd się powtarza, nacisk zmienia się z odzyskiwania dostępu do sieci na ustalenie, co powoduje to zakłócenie.

Tabela poniżej służy jako przydatny przewodnik do rozwiązywania problemów:

Obserwowany objaw	Priorytet dochodzenia
Jeden użytkownik nie może ponownie połączyć.	Zablokowana sesja lub profil użytkownika
Wielu użytkowników nie może się połączyć	Stan usługi, zasoby, przetwarzanie sesji
Niepowodzenie podczas logowania porannego	Logowania równoległe, ładowanie profilu, przechowywanie
Restart tymczasowo rozwiązuje błąd	Wycieki pamięci lub sesji
Błąd następuje po aktualizacji oprogramowania zabezpieczającego	Interakcje z oprogramowaniem firm trzecich
Błąd następuje po zmianach w zasadach grupy	Przetwarzanie polityki i uprawnienia logowania
Logowanie do konsoli również nie powiodło się	Szersze problemy z logowaniem do systemu Windows lub systemem
Istniejące sesje działają, ale nowi użytkownicy nie mogą się połączyć.	Ograniczenia połączeń, tryb oszczędzania, licencjonowanie

Te wzorce sugerują priorytety dochodzenia, a nie definitywne diagnozy.

Zbierz dowody diagnostyczne przed ponownym uruchomieniem

W przypadku sporadycznych awarii zbierz odpowiednie dzienniki i dane dotyczące wydajności przed ponownym uruchomieniem serwera, gdy tylko będzie to operacyjnie możliwe.

Microsoft udostępnia narzędzie TroubleShootingScript (TSS) do zbierania śladów diagnostycznych.

W zależności od scenariusza, administratorzy mogą przechwytywać ślady klientów RDP:

.TSS.ps1 -Scenariusz UEX_RDSCli

I ślady po stronie serwera:

.TSS.ps1 -Scenariusz UEX_RDSSrv

Użyj aktualnej dokumentacji Microsoft TSS, aby potwierdzić obsługiwane scenariusze, wymagania wstępne i procedury wykonania.

W przypadku bardziej złożonych awarii może być konieczne dodatkowe zbieranie pamięci lub wydajności. Takie diagnostyki powinny być starannie planowane, ponieważ mogą wpływać na systemy produkcyjne i mogą zawierać wrażliwe informacje.

W przypadku wdrożeń wieloserwerowych uwzględnij komponenty RD Connection Broker i RD Gateway w badaniu, gdy ścieżka połączenia obejmuje te usługi.

Jak możesz zapobiec tym błędom?

Nie wszystkie awarie RDS są zapobiegane. Ale są kroki, które możesz podjąć, w tym ciągłe monitorowanie, odpowiednie zasady sesji i ograniczona konserwacja oprogramowania.

Monitorowanie zasobów serwera i aktywności sesji

Monitorowanie środowiska RDS przez śledzenie CPU, pamięci, dysku , a jednocześnie zalogowane sesje.

Patrz na trendy, a nie na progi. Analiza podstawowa jest szczególnie ważna przy rozwiązywaniu problemów, które pojawiają się w godzinach szczytu lub stopniowo po ponownym uruchomieniu serwerów.

Monitoruj system, aby odróżnić problemy z pojemnością od awarii, które nadal występują pomimo wystarczających zasobów.

Skonfiguruj czasy wygaśnięcia sesji ostrożnie

Przeglądaj zasady regulujące rozłączone i nieaktywne sesje. Microsoft Learn wyjaśnia, jak rozróżniać nieoczekiwane blokady sesji i rozłączenia i zbadać polityki czasu oczekiwania sesji odpowiedzialne za te zachowania.

Dobrze dobrane wartości czasu oczekiwania zapobiegają niepotrzebnemu utrzymywaniu sesji i zajmowaniu zasobów. Zbyt agresywne polityki czasu oczekiwania mogą jednak zniszczyć produktywne sesje robocze, kończąc je przed zakończeniem krytycznych operacji.

Polityki czasu oczekiwania sesji powinny być oparte na wymaganiach biznesowych i nie powinny być stosowane jako lekarstwo na podstawowe wycieki sesji.

Zarządzaj oprogramowaniem związanym z systemem Windows i sesjami

Wdrażaj obsługiwane aktualizacje i poprawki systemu Windows Server dla konkretnych problemów.

Upewnij się, że agenci ochrony punktów końcowych, komponenty zarządzania profilami, komponenty wirtualizacji i aplikacje zintegrowane z sesją są zgodne z systemem operacyjnym.

Przetestuj aktualizacje w środowisku przedprodukcyjnym, szczególnie jeśli w procesie logowania do systemu Windows lub sesji zaangażowanych jest wiele komponentów firm trzecich.

Przegląd pojemności i konfiguracji RDS

Rozmiar hostów sesji pulpitu zdalnego zgodnie z realistycznymi jednoczesnymi obciążeniami, biorąc pod uwagę godziny szczytu dla logowania i uruchamiania programów.

Rozważ rozdzielenie sesji między wiele hostów w większych środowiskach, aby uniknąć zatorów.

Audyt polityki grupowej, ograniczeń połączeń, konfiguracji licencji i praktyk konserwacyjnych w celu regularnego odkrywania i eliminowania potencjalnych przyczyn awarii połączeń.

Szukasz prostszego zdalnego pulpitu i dostarczania aplikacji?

Rozwiązywanie problemów z usługami pulpitu zdalnego może uwydatnić wysiłek administracyjny związany z utrzymywaniem środowisk dostarczania aplikacji Windows. Dla organizacji, które przede wszystkim muszą zapewnić użytkownikom aplikacje Windows lub pełne pulpity zdalne, przeglądanie złożoności ich istniejącej infrastruktury może być warte zachodu.

TSplus Zdalny Dostęp oferuje uproszczone podejście do publikacji aplikacji Windows dla wielu użytkowników oraz dostarczania pulpitu zdalnego, z dostępem opartym na przeglądarce i centralnym zarządzaniem. Pomaga zespołom IT udostępniać aplikacje użytkownikom zdalnym bez wdrażania pełnej złożoności tradycyjnej infrastruktury Microsoft RDS, jednocześnie wymagając odpowiedniego utrzymania i zabezpieczeń serwera Windows.

Wniosek

Błąd "Usługi pulpitu zdalnego są obecnie zajęte" wymaga więcej niż rutynowego ponownego uruchomienia serwera. Zidentyfikowanie, czy awaria pochodzi z zablokowanej sesji, ograniczenia zasobów czy problemu z logowaniem do systemu Windows, pozwala administratorom wybrać najmniej zakłócające rozwiązanie.

Gdy błędy się powtarzają lub wracają, systematyczna diagnostyka, monitorowanie wydajności i przeglądy konfiguracji są niezbędne do rozwiązania ich podstawowych przyczyn i utrzymania niezawodnej łączności RDP.