Kończysz skrypt w Windows PowerShell i zastanawiasz się, czy uruchomi się też w nowszym środowisku? PowerShell 7 można zainstalować obok wersji 5.1, choć zgodność starszych modułów zależy od tego, jak zostały zbudowane i z jakich funkcji Windows korzystają.
Najpierw sprawdź moduły, potem wybierz sposób instalacji
- PowerShell 7 działa równolegle z Windows PowerShell 5.1.
- Wersja LTS jest rozsądnym wyborem do codziennej pracy i projektów.
- Starszy moduł może działać przez warstwę zgodności, ale nie każdy obiekt zachowa się w niej jak natywny.
- Microsoft Store upraszcza aktualizacje, za to ma ograniczenia przy zdalnym zarządzaniu.
PowerShell 7.6 LTS to aktualna linia do pracy na Windows
W menu Start możesz zobaczyć dwie aplikacje o podobnej nazwie i łatwo uznać, że jedna zastąpiła drugą. Windows PowerShell 5.1 jest częścią systemowego środowiska, a PowerShell 7 to osobna, rozwijana aplikacja uruchamiana poleceniem pwsh.
W aktualnej linii wydań PowerShell 7.6 ma status LTS i bazuje na .NET 10. Microsoft podaje koniec wsparcia tej wersji na 15 listopada 2028 roku. Dla osoby pracującej z .NET to wygodny wybór: środowisko skryptowe korzysta z nowszej platformy, a wydanie LTS ma określony, dłuższy okres wsparcia.
Ja wybierałbym wydanie LTS do regularnej pracy, a wersję podglądową zostawił do sprawdzania nowości. Pamiętaj przy tym, że aktualizacja PowerShella nie aktualizuje automatycznie skryptów, które uruchamiasz z Harmonogramu zadań albo z aplikacji zewnętrznej. Tam liczy się ścieżka do konkretnego pliku wykonywalnego.
Sposób instalacji dobierz do tego, czy potrzebujesz remoting
Jeśli chcesz po prostu uruchamiać polecenia lokalnie, instalacja z Microsoft Store jest wygodna. Gdy konfigurujesz zdalne sesje lub środowisko dla wielu użytkowników, wybór pakietu zaczyna mieć większe konsekwencje.
Microsoft Learn wskazuje WinGet jako zalecaną metodę na komputerach klienckich z Windows. W 2026 roku pakiet WinGet dla linii 7.6 instaluje domyślnie wersję MSIX. Taki pakiet aktualizuje się w wygodny sposób, ale działa w modelu aplikacji dla pojedynczego użytkownika i nie obsługuje przychodzącego PowerShell Remoting.
| Sytuacja | Wybór | Skutek |
|---|---|---|
| Praca lokalna, automatyczne aktualizacje | Microsoft Store lub WinGet z domyślnym MSIX | Prosta instalacja dla konta użytkownika, bez przychodzących sesji remoting |
| Konfiguracja remoting lub wdrożenie dla zespołu | Pakiet MSI | Instalacja systemowa z opcjami dla administratora |
| Test bez uprawnień administratora albo osobna kopia | Archiwum ZIP | Uruchamiasz pwsh.exe z wybranego katalogu, a skrót i ścieżkę PATH konfigurujesz samodzielnie |
Wybierz MSI, jeśli komputer ma przyjmować połączenia zdalne albo instalacją zarządza administrator. Przy lokalnym użyciu MSIX zwykle wystarczy, ale ograniczenia pakietu mogą zaskoczyć, gdy później zechcesz skonfigurować maszynę jak serwer.
Moduł z wersji 5.1 może działać przez proces pośredniczący
Najczęstszy zgrzyt po instalacji pojawia się przy poleceniu Import-Module. Sam fakt, że moduł działa w Windows PowerShell 5.1, nie gwarantuje natywnej zgodności z PowerShellem 7. Microsoft wymienia między innymi moduły Azure PowerShell i Active Directory jako zgodne, ale przy konkretnym skrypcie trzeba sprawdzić również używane polecenia i typy obiektów.
Na Windows można spróbować wczytać niezgodny moduł przez Import-Module -Name ScheduledTasks -UseWindowsPowerShell. PowerShell 7 uruchamia wtedy proces Windows PowerShell 5.1 w tle i przekazuje mu polecenia przez implicit remoting, czyli zdalne wywołania, które w tym wypadku odbywają się lokalnie.
Pułapka kryje się w zwracanych obiektach. Parametry i wyniki są serializowane, więc obiekt po przejściu przez warstwę zgodności może stracić metody dostępne w oryginalnej sesji. Gdy skrypt tylko pobiera listę zadań i wyświetla ich właściwości, obejście może wystarczyć. Jeśli wywołuje metody obiektu albo przekazuje go dalej do kodu .NET, bezpieczniej uruchomić ten fragment w Windows PowerShell 5.1 lub znaleźć natywnie zgodny moduł.
Po instalacji sprawdź wersję, profil i ścieżkę skryptu
Dwie wersje mogą być zainstalowane równolegle, ale nie korzystają z identycznego profilu użytkownika ani katalogów modułów. Dlatego ustawienia terminala, funkcje z profilu i moduły dodane wyłącznie dla 5.1 mogą nie pojawić się po otwarciu nowej konsoli.
W nowym oknie PowerShella uruchom $PSVersionTable.PSVersion, aby sprawdzić wersję sesji, a $PROFILE, by zobaczyć aktywny plik profilu. Jeśli uruchamiasz skrypt z Visual Studio Code, Harmonogramu zadań lub innej aplikacji, upewnij się też, że jej konfiguracja wskazuje na pwsh.exe, a nie na powershell.exe.
| Sytuacja | Prawdopodobna przyczyna | Co zrobić |
|---|---|---|
| Moduł jest widoczny w 5.1, ale nie w 7 | Inne ścieżki modułów albo brak zgodności z PowerShellem 7 | Sprawdź $env:PSModulePath i manifest modułu; nie kopiuj w ciemno całego katalogu modułów |
| Profil nie ustawia aliasów lub funkcji | PowerShell 7 używa osobnej lokalizacji profilu | Otwórz ścieżkę z $PROFILE i przenieś potrzebne ustawienia po sprawdzeniu ich zgodności |
| Sesja zdalna nie łączy się z nowym środowiskiem | Pakiet MSIX nie obsługuje przychodzącego remoting | Wybierz MSI i skonfiguruj osobny punkt końcowy dla tej instalacji |
Jest jeszcze jeden szczegół: Windows PowerShell ISE pozostaje edytorem dla wersji 5.1. Nie hostuje PowerShella 7, więc do pracy nad skryptami dla nowszej wersji użyj terminala lub edytora, który pozwala wybrać właściwy plik wykonywalny.
Zachowaj obie wersje, dopóki skrypty nie przejdą kontroli
Najspokojniejsza migracja zaczyna się od uruchomienia dotychczasowego skryptu w obu powłokach i porównania wyników, szczególnie gdy skrypt korzysta z modułów Windows albo bezpośrednio wywołuje metody .NET. Wiele osób docenia możliwość pozostawienia wersji 5.1 pod starsze narzędzia, bo nie trzeba od razu przebudowywać całego środowiska.
Jeśli skrypt działa poprawnie w PowerShellu 7, ustaw tę wersję jako domyślną w edytorze lub zadaniu automatycznym. Gdy natrafisz na problem z modułem, uruchom tylko ten fragment w 5.1 albo sprawdź tryb zgodności, zamiast zgadywać, że instalacja się nie powiodła. Dzięki temu nowa wersja może obsługiwać codzienną pracę, a starsza zostaje pod ręką dla zależności, które jeszcze jej wymagają.
