PowerShell nie działa na koncie użytkownika

PowerShell niedziałający na koncie użytkownika wskazuje na politykę Execution Policy ograniczoną do kont administracyjnych.

Jak rozpoznać problem z uruchamianiem PowerShell na koncie użytkownika

Komunikat, że PowerShell działa na koncie administratora, ale nie uruchamia się na zwykłym koncie użytkownika, nie oznacza automatycznie, że przyczyną jest sama polityka Execution Policy ograniczona do administratorów. W systemie Windows zasady wykonywania skryptów PowerShell są konfigurowane według zakresów: MachinePolicy, UserPolicy, Process, CurrentUser i LocalMachine. Dwie pierwsze wartości mogą być narzucone przez zasady grupy, a pozostałe są ustawieniami lokalnymi powiązanymi z procesem, użytkownikiem albo komputerem.

Objaw może mieć kilka postaci. PowerShell może nie otwierać się w ogóle, uruchamiać się i natychmiast zamykać, pozwalać na wpisywanie poleceń, ale blokować pliki skryptów albo zwracać błąd dotyczący niedozwolonego wykonywania skryptu. Trzeba odróżnić te sytuacje, ponieważ Execution Policy dotyczy przede wszystkim uruchamiania skryptów PowerShell, a nie każdego sposobu otwierania powłoki. Jeżeli nie startuje sama aplikacja powershell.exe lub pwsh.exe, przyczyny należy szukać także w uprawnieniach systemowych, blokadach aplikacji, konfiguracji profilu oraz uszkodzeniu instalacji.

Zakresy Execution Policy i zasady przypisane do użytkownika

Execution Policy nie jest klasycznym mechanizmem nadawania praw dostępu do plików. Określa, jakie skrypty PowerShell mogą zostać uruchomione, ale nie zastępuje uprawnień NTFS, kontroli kont użytkowników ani zasad bezpieczeństwa systemu Windows. Typowa polityka może zezwalać na polecenia wpisywane interaktywnie, a jednocześnie wymagać podpisu cyfrowego dla skryptów pobranych z internetu. Inna konfiguracja może całkowicie blokować wykonywanie skryptów, lecz nadal pozwalać na otwarcie konsoli.

Istotne jest ustalenie, czy ograniczenie pochodzi z zakresu UserPolicy, MachinePolicy, CurrentUser czy LocalMachine. Zasada grupy ustawiona dla użytkownika może obowiązywać niezależnie od lokalnej konfiguracji komputera i zwykle ma wyższy priorytet niż ustawienia zapisane przez pojedynczego użytkownika. Administrator może więc uruchamiać PowerShell w innym kontekście zasad niż konto standardowe, zwłaszcza gdy komputery lub konta należą do różnych jednostek organizacyjnych albo otrzymują odmienne ustawienia zabezpieczeń.

Różnicę może powodować także profil użytkownika. Ustawienie zapisane w zakresie CurrentUser dotyczy konkretnego konta, dlatego zmiana konfiguracji wykonana dla administratora nie musi wpływać na zwykłego użytkownika. Z kolei ustawienie LocalMachine odnosi się do całego komputera i zazwyczaj wymaga podwyższonych uprawnień do modyfikacji. Sama próba uruchomienia PowerShell jako administrator nie jest jednak prawidłową metodą usuwania ograniczenia, jeżeli blokada wynika z centralnej zasady bezpieczeństwa.

Blokada skryptu a blokada programu PowerShell

W diagnostyce trzeba sprawdzić, czy problem występuje przy otwieraniu powłoki, czy dopiero przy wykonywaniu konkretnego pliku. Jeśli okno PowerShell otwiera się, lecz skrypt nie zostaje uruchomiony, możliwe są ograniczenia Execution Policy, brak odpowiednich praw do pliku, oznaczenie pliku jako pobranego z zewnętrznego źródła albo blokada przez oprogramowanie zabezpieczające. Jeżeli użytkownik nie może nawet uruchomić programu, bardziej prawdopodobne są zasady AppLocker, Windows Defender Application Control, ograniczenie przez oprogramowanie ochronne, uszkodzone skojarzenia lub problem z profilem.

Znaczenie ma również wersja używanej powłoki. Windows PowerShell 5.1 jest składnikiem systemu Windows i korzysta z programu powershell.exe, natomiast nowszy, wieloplatformowy PowerShell jest uruchamiany jako pwsh.exe. Są to odrębne programy, dlatego możliwość uruchomienia jednej powłoki nie dowodzi poprawnego działania drugiej. Skrypt może też wymagać modułu, profilu użytkownika albo konkretnej wersji środowiska. W takiej sytuacji komunikat o niedziałającym PowerShell może w rzeczywistości oznaczać brak zależności, błędną ścieżkę do modułu lub błąd w profilu ładowanym podczas startu.

Bezpieczna diagnostyka powinna porównać zachowanie obu kont na tym samym komputerze, sprawdzić dokładną treść komunikatu i ustalić, czy blokada dotyczy wszystkich skryptów, jednego pliku, czy całego programu. Należy także zweryfikować, czy konto użytkownika ma dostęp do lokalizacji, z której uruchamiany jest skrypt, oraz czy profil nie zawiera poleceń powodujących błąd podczas inicjalizacji. Zmiana polityki bez ustalenia jej źródła może naruszyć przyjęte zasady bezpieczeństwa i nie usunąć blokady wymuszanej centralnie.

Naprawa konfiguracji powłoki na komputerze użytkownika

Naprawa zależy od wyniku rozróżnienia między blokadą skryptów a blokadą aplikacji. W przypadku lokalnego ustawienia użytkownika można przywrócić zgodną konfigurację właściwego zakresu, usunąć błędną zawartość profilu PowerShell albo odtworzyć brakujące składniki systemowe. Jeżeli ograniczenie pochodzi z zasad grupy, konieczna jest korekta reguły przez osobę uprawnioną do zarządzania konfiguracją Windows. Lokalne obejście takiej zasady może nie działać, a dodatkowo może pozostawać sprzeczne z polityką bezpieczeństwa obowiązującą na komputerze.

Przed modyfikacją warto zabezpieczyć dane użytkownika i ustalić, czy problem pojawia się po zalogowaniu na nowym profilu. Taki test pomaga oddzielić uszkodzenie profilu od problemu systemowego. Należy również sprawdzić integralność składników PowerShell, działanie usług ochrony oraz wpisy rejestrowane w Podglądzie zdarzeń, jeżeli program jest blokowany przez regułę aplikacyjną. W środowisku domowym lub biurowym Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnozowaniem problemów z oprogramowaniem systemowym.