PowerShell nie działa w sesji zdalnej

PowerShell niedziałający w sesji zdalnej wskazuje na wyłączony PowerShell Remoting (WinRM) na komputerze docelowym.

Co oznacza brak działania PowerShell w sesji zdalnej

Komunikat informujący, że PowerShell nie działa w sesji zdalnej, oznacza problem z uruchomieniem albo utrzymaniem połączenia między komputerem administrującym a komputerem docelowym. W typowym połączeniu wykorzystuje się usługę Windows Remote Management, czyli WinRM, która udostępnia interfejs zarządzania oparty na protokole WS-Management. Sam program PowerShell może być zainstalowany i działać lokalnie, a mimo to polecenia zdalne nie będą wykonywane, jeżeli komputer docelowy nie przyjmuje żądań WinRM.

Jedną z podstawowych przyczyn jest wyłączona albo niepoprawnie skonfigurowana funkcja PowerShell Remoting na komputerze docelowym. Nie jest to jednak jedyne możliwe źródło problemu. Błąd może wynikać także z niedostępności hosta, blokady zapory sieciowej, nieprawidłowej nazwy komputera, braku uprawnień, odrzucenia mechanizmu uwierzytelniania lub niezgodności konfiguracji zaufanych hostów. Dlatego sama obecność błędu nie przesądza jeszcze, że usługa WinRM jest wyłączona; wskazuje natomiast, że należy sprawdzić cały łańcuch komunikacji.

WinRM, nasłuch i port używany przez połączenie

PowerShell Remoting korzysta z usługi WinRM działającej na komputerze docelowym. Standardowa konfiguracja HTTP używa portu TCP 5985, natomiast połączenie zabezpieczone przez HTTPS korzysta z portu TCP 5986. Port musi być osiągalny z komputera źródłowego, a zapora systemu Windows musi zezwalać na odpowiedni ruch przychodzący. Jeżeli usługa nie działa, nie ma skonfigurowanego listenera albo reguła zapory blokuje komunikację, polecenie Enter-PSSession, Invoke-Command lub podobna operacja zakończy się błędem połączenia.

Na komputerze docelowym stan konfiguracji można sprawdzić poleceniami Get-Service WinRM oraz winrm enumerate winrm/config/listener. Pierwsze polecenie pokazuje stan usługi, a drugie pozwala sprawdzić, czy istnieje listener nasłuchujący na właściwym adresie i porcie. Z komputera źródłowego przydatne jest polecenie Test-WSMan nazwa-komputera, które testuje dostępność interfejsu WS-Management. Należy odróżnić błąd braku odpowiedzi od błędu autoryzacji: pierwszy zwykle kieruje uwagę na sieć, usługę, listener lub zaporę, a drugi na konto i sposób uwierzytelniania.

Uwierzytelnianie, TrustedHosts i zakres uprawnień

Nawet sprawny WinRM nie gwarantuje udanej sesji. Komputer źródłowy musi zostać uwierzytelniony przez hosta docelowego, a użyte konto musi mieć uprawnienia wymagane do wykonania konkretnego polecenia. W środowisku domenowym często stosowany jest mechanizm Kerberos, który wymaga poprawnej rozpoznawalności nazw komputerów i prawidłowej zależności domenowej. Przy połączeniach poza domeną mogą pojawić się wymagania dotyczące listy TrustedHosts albo konieczność jawnego podania danych uwierzytelniających za pomocą parametru -Credential.

Listę zaufanych hostów można odczytać poleceniem Get-Item WSMan:\localhost\Client\TrustedHosts. Nie należy bez potrzeby ustawiać wartości *, ponieważ oznacza ona zaufanie do wszystkich hostów i osłabia kontrolę nad tym, z jakimi komputerami klient może nawiązywać połączenia. Bezpieczniejsza diagnostyka polega na sprawdzeniu konkretnej nazwy lub adresu, poprawności rozwiązywania DNS oraz zgodności nazwy użytej w poleceniu z konfiguracją certyfikatu, jeśli wykorzystywany jest HTTPS. W przypadku sesji do podwyższonego poziomu administracyjnego znaczenie mogą mieć również zasady UAC, członkostwo konta w odpowiedniej grupie oraz ograniczenia zdefiniowane w konfiguracji endpointu PowerShell.

Postępowanie przy przywracaniu sesji zdalnej

Diagnostykę warto prowadzić od najprostszego testu do elementów wymagających zmiany konfiguracji. Najpierw należy sprawdzić, czy komputer docelowy odpowiada w sieci, czy jego nazwa jest prawidłowo rozwiązywana oraz czy port 5985 albo 5986 jest osiągalny. Następnie można użyć Test-WSMan, sprawdzić usługę WinRM, listener i reguły zapory. Jeżeli funkcja zdalnego zarządzania nie została skonfigurowana, na komputerze docelowym można zastosować Enable-PSRemoting, ale polecenie powinno być wykonywane świadomie, z uwzględnieniem profilu sieciowego i obowiązujących zasad bezpieczeństwa.

Po przywróceniu komunikacji trzeba jeszcze potwierdzić działanie właściwej sesji, na przykład przez Enter-PSSession -ComputerName nazwa-komputera albo testowe wykonanie polecenia Invoke-Command -ComputerName nazwa-komputera -ScriptBlock { hostname }. Jeżeli połączenie zostaje ustanowione, lecz konkretna komenda nadal nie działa, problem może dotyczyć polityki wykonywania skryptów, dostępnych modułów, ścieżek lub uprawnień w samej sesji. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w ramach diagnostyki można ustalić, czy przyczyną jest konfiguracja systemu Windows, sieć, usługa WinRM czy błąd uprawnień.