PowerShell pokazuje inny typ profilu niż GUI

PowerShell pokazujący inny typ profilu niż GUI wskazuje na rozbieżność między profilem $PROFILE dla konsoli a interfejsem graficznym Windows Terminal.

PowerShell pokazuje inny typ profilu niż GUI — czym jest ta rozbieżność

Komunikat lub obserwacja, że PowerShell pokazuje inny typ profilu niż GUI, zwykle oznacza, że porównywane są dwa różne środowiska uruchomieniowe albo dwa różne źródła informacji o koncie. W systemie Windows profil użytkownika może być opisywany na kilka sposobów. Jedna informacja pochodzi z lokalnej konfiguracji systemu, inna z zasad domenowych lub konta zarządzanego, a jeszcze inna z ustawień używanych przez konkretną powłokę. Graficzny panel ustawień może prezentować uproszczoną nazwę albo kategorię profilu, natomiast PowerShell może odczytywać właściwość techniczną zapisaną w rejestrze, obiekcie systemowym lub wyniku polecenia administracyjnego.

Nie musi to oznaczać uszkodzenia systemu. Często jest to skutek zastosowania różnych definicji słowa „profil”. W interfejsie graficznym może chodzić o typ konta, na przykład konto lokalne lub konto połączone z usługą internetową. W PowerShellu określenie to może odnosić się do pliku startowego powłoki, lokalizacji katalogu użytkownika, rodzaju sesji albo właściwości zabezpieczeń. Dodatkowo Windows Terminal, klasyczna konsola, PowerShell uruchomiony jako administrator oraz PowerShell uruchomiony w zwykłym trybie mogą korzystać z odmiennych ustawień.

W praktyce ważne jest ustalenie, co dokładnie zostało porównane. Samo słowo „profil” nie wystarcza do oceny sytuacji. Należy rozróżnić profil konta Windows od profilu PowerShell, czyli skryptu wykonywanego przy uruchomieniu powłoki. Ten drugi może być zapisany w kilku lokalizacjach, zależnie od zakresu obowiązywania: dla bieżącego użytkownika, dla wszystkich użytkowników, dla konkretnej wersji powłoki albo dla konkretnego hosta, takiego jak Windows Terminal.

PowerShell pokazuje inny typ profilu niż GUI — kontekst techniczny i porównanie

Najczęstszym źródłem nieporozumienia jest zmienna $PROFILE. Nie opisuje ona typu konta Windows. Wskazuje ścieżkę do pliku profilu PowerShell, który może zawierać polecenia, funkcje, aliasy, zmienne środowiskowe oraz ustawienia wyglądu sesji. Wartość tej zmiennej jest związana z używaną powłoką i hostem. Z tego powodu jej wynik w jednej sesji nie musi być identyczny z wynikiem uzyskanym w innej sesji.

W PowerShellu dostępne są zwykle cztery warianty ścieżki profilu: profil bieżącego użytkownika dla bieżącego hosta, profil wszystkich użytkowników dla bieżącego hosta, profil bieżącego użytkownika wspólny dla hostów oraz profil wszystkich użytkowników wspólny dla hostów. Zastosowany host może zmienić wartość $PROFILE, a inna wersja PowerShell może korzystać z innego katalogu. Dlatego uruchomienie powłoki w Windows Terminal, w edytorze skryptów albo w starszej konsoli może dać różne rezultaty.

Interfejs graficzny nie musi znać tych plików ani ich odczytywać. Panel ustawień może wskazywać, że konto ma określony typ, podczas gdy PowerShell wyświetla właściwość dotyczącą profilu sesji. To porównanie przypomina zestawienie nazwy użytkownika z nazwą katalogu domowego: obie informacje dotyczą tej samej osoby, lecz opisują inne elementy systemu. Różnica jest szczególnie widoczna po zmianie wersji powłoki, przeniesieniu katalogu użytkownika, odtworzeniu ustawień lub wdrożeniu zasad administracyjnych.

Do uporządkowania sytuacji przydatne jest sprawdzenie kilku wartości w tej samej sesji. Polecenie $PROFILE | Format-List * nie zawsze dostarczy wszystkich potrzebnych informacji, ponieważ $PROFILE jest obiektem typu ścieżkowego. Można natomiast wyświetlić wartość $PROFILE, użyć Test-Path $PROFILE w celu sprawdzenia, czy plik istnieje, oraz obejrzeć wszystkie warianty przez $PROFILE | Get-Member i właściwości profilu dostępne w danej wersji. Warto również odnotować nazwę hosta, wersję powłoki i poziom uprawnień.

PowerShell pokazuje inny typ profilu niż GUI — typowe problemy

Jednym z częstych przypadków jest uruchomienie PowerShella w innej wersji niż ta, dla której przygotowano plik profilu. PowerShell 5.1 i nowsze wydania PowerShell mogą używać odmiennych katalogów oraz odmiennych modułów. Skrypt, który działał w jednym środowisku, może nie być ładowany w drugim. Wtedy interfejs graficzny pokazuje prawidłowy typ konta, a powłoka zachowuje się tak, jakby profil był pusty lub należał do innego środowiska.

Inny problem powstaje po włączeniu opcji uruchamiania jako administrator. Taka sesja nadal może należeć do tego samego użytkownika, ale jej ustawienia, zmienne i dostęp do części zasobów są odrębne. Gdy profil jest tworzony lub edytowany w sesji podwyższonych uprawnień, łatwo uznać, że zmiana dotyczy każdej sesji. W rzeczywistości plik może znajdować się w innej lokalizacji albo być objęty innymi regułami.

Rozbieżność bywa również powodowana przez zmienną środowiskową USERPROFILE, przekierowanie folderu Dokumenty, synchronizację ustawień oraz zasady ograniczające wykonywanie skryptów. Jeżeli profil znajduje się w lokalizacji, która nie jest dostępna przy starcie powłoki, jego polecenia nie zostaną wykonane. Czasem błąd jest widoczny w komunikacie przy uruchamianiu, lecz czasem skutki są pośrednie: brakuje aliasu, funkcji, ustawienia kodowania albo zmodyfikowanego promptu.

Warto odróżnić typ profilu od polityki wykonywania skryptów. Polecenie Get-ExecutionPolicy -List pokazuje zasady obowiązujące w różnych zakresach, ale nie określa rodzaju konta i nie zmienia lokalizacji pliku $PROFILE. Podobnie informacja o koncie lokalnym, służbowym lub połączonym z usługą nie mówi, czy konkretny skrypt startowy został znaleziony i uruchomiony. Łączenie tych informacji w jedną kategorię prowadzi do błędnej diagnozy.

Problemy mogą pojawić się także po zmianie nazwy użytkownika, odtworzeniu systemu z kopii lub przeniesieniu danych na inny dysk. Wtedy graficzny panel może prezentować aktualny stan konta, a stare ścieżki zapisane w profilu PowerShell nadal wskazują nieistniejące foldery. Podobny efekt daje ręczna edycja rejestru albo skopiowanie profilu z innego komputera bez dostosowania ścieżek.

PowerShell pokazuje inny typ profilu niż GUI — praktyczne wskazówki diagnostyczne

Najbezpieczniej rozpocząć od zebrania informacji bez wprowadzania zmian. Należy uruchomić dokładnie tę sesję, w której występuje rozbieżność, a następnie zapisać wynik poleceń dotyczących wersji, hosta, użytkownika i ścieżek. Przydatne są między innymi $PSVersionTable, $Host.Name, [Environment]::UserName, [Environment]::UserDomainName, $env:USERPROFILE oraz $PROFILE. Każdą wartość powinno się interpretować w kontekście pozostałych, ponieważ pojedynczy wynik nie rozstrzyga sprawy.

Następnie można sprawdzić obecność profilu oraz jego zawartość. Test-Path -LiteralPath $PROFILE odpowiada na pytanie, czy plik istnieje pod aktualną ścieżką. Jeżeli wynik jest pozytywny, pomocne jest odczytanie pliku w trybie tylko do odczytu i zwrócenie uwagi na polecenia zmieniające ścieżki, zmienne, kodowanie lub ładowane moduły. Nie powinno się bezpośrednio kopiować całej zawartości profilu między komputerami, ponieważ mogą się w niej znajdować ścieżki właściwe dla konkretnego środowiska.

Do porównania z interfejsem graficznym należy użyć tych samych danych identyfikujących konto. Warto sprawdzić, czy panel został otwarty w tym samym kontekście użytkownika, czy sesja PowerShella nie działa z podwyższonymi uprawnieniami oraz czy Windows Terminal nie uruchamia innego programu niż zakładany. Dobrą praktyką jest zamknięcie wszystkich dodatkowych sesji, otwarcie jednej zwykłej sesji i powtórzenie pomiaru. Dopiero potem można porównać wynik z sesją administratora lub innym hostem.

Jeżeli problem dotyczy tylko wyglądu promptu albo dostępności własnych funkcji, przyczyną może być brak pliku profilu, błędna nazwa pliku lub jego zablokowanie przez ustawienia bezpieczeństwa. Jeżeli natomiast inny typ jest widoczny przy danych konta, trzeba sprawdzić źródło informacji używane przez polecenie i panel. Pomocne jest dokumentowanie pełnych ścieżek, nazw hostów, wersji powłoki i czasu wystąpienia problemu. Taki zapis ułatwia odtworzenie warunków i ogranicza ryzyko przypadkowej zmiany ustawień.

PowerShell pokazuje inny typ profilu niż GUI — kiedy zgłosić się do serwisu

Do konsultacji warto skierować sytuację, w której różnica pojawia się w kilku sesjach, po każdorazowym uruchomieniu systemu albo po zmianie konta. Szczególnej uwagi wymaga brak dostępu do własnego katalogu, samoczynne zmiany ścieżek, komunikaty o błędach profilu, znikające ustawienia oraz sytuacja, w której PowerShell wykonuje nieznane polecenia przy starcie. Przed przekazaniem komputera dobrze jest zanotować dokładne brzmienie komunikatu, nazwę używanego hosta i informację, czy problem występuje w sesji zwykłej, czy podwyższonej.

W przypadku komputera używanego do pracy, nauki lub obsługi ważnych danych nie powinno się usuwać profilu użytkownika ani kasować plików konfiguracyjnych bez kopii zapasowej. Nie należy też zmieniać przypadkowo zasad wykonywania skryptów, ponieważ może to ukryć przyczynę albo naruszyć ustalenia bezpieczeństwa. W pierwszej kolejności powinno się ustalić, czy błąd dotyczy konta Windows, pliku profilu PowerShell, hosta, wersji powłoki, uprawnień czy ścieżki do danych.

W Warszawie takie rozbieżności można skonsultować z serwisem Warszawskie Pogotowie Komputerowe 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu przydatne będzie przedstawienie wyników podstawowych poleceń, opisu różnicy między panelem graficznym a konsolą oraz informacji o ostatnich zmianach w systemie. Pozwala to szybciej odtworzyć warunki występowania problemu i ocenić, czy potrzebna jest korekta profilu, uporządkowanie ustawień powłoki, naprawa dostępu do katalogów czy dodatkowa kontrola konfiguracji użytkownika.