Jak zacząć z PowerShell i nie przestraszyć się konsoli w Windows 10 i 11

„Uruchom PowerShell jako administrator i wpisz…” — to zdanie potrafi zablokować, nawet jeśli na co dzień sprawnie ogarniasz Windows 10 lub Windows 11. Konsola wygląda „groźnie”, komunikaty bywają techniczne, a w głowie od razu pojawia się pytanie: czy ja sobie tym nie popsuję systemu?

Da się wejść w PowerShell spokojnie i bezpiecznie. Klucz to zrozumieć kilka mechanizmów (cmdlety, obiekty, potok), nauczyć się czytać polecenia przed naciśnięciem Enter i zacząć od rzeczy, które tylko odczytują informacje. Dopiero potem przychodzi czas na działania modyfikujące (zmiana, usuwanie, zatrzymywanie usług). Ten tekst jest zbudowany wokół pytań, które realnie zatrzymują początkujących: po co PowerShell, jak go uruchomić w Windows 10/11, kiedy potrzebujesz admina, co oznaczają parametry i jak testować bez ryzyka.

PowerShell Windows 11, PowerShell Windows 10, Windows Terminal PowerShell, PowerShell jako administrator, podstawowe komendy PowerShell, Get-Help Get-Command, pipeline PowerShell, Execution Policy, PowerShell 5.1 vs 7, zapis wyniku do pliku PowerShell, bezpieczne polecenia Get Set Remove, autouzupełnianie i historia poleceń

Pierwsze pytania, które blokują start: czy to bezpieczne i po co w ogóle konsola?

„Czy mogę coś zepsuć?” – realny poziom ryzyka

Ryzyko w PowerShell nie wynika z tego, że to „czarna konsola”, tylko z tego, że można w niej wykonywać polecenia, które zmieniają system szybciej niż klikanie w GUI. To działa w dwie strony: szybciej zrobisz porządek, ale też szybciej popełnisz błąd, jeśli uruchomisz coś bez zrozumienia.

Najprostsza zasada, która uspokaja start: najpierw odczyt, potem zmiana. W PowerShell widać to już w nazwach poleceń: cmdlety zaczynające się od Get- zwykle tylko pobierają dane (procesy, usługi, pliki, konfigurację). Dopiero Set-, Remove-, Stop-, Restart-, New- robią zmiany.

Druga rzecz: uprawnienia. Jeśli uruchomisz PowerShell jako zwykły użytkownik, wiele ryzykownych operacji po prostu się nie uda (dostaniesz „Access is denied” / „Unauthorized”). To nie zwalnia z myślenia, ale działa jak podstawowy bezpiecznik.

PowerShell vs CMD: trzy różnice, które zmieniają sposób pracy

Klasyczny CMD (Wiersz polecenia) jest tekstowy: uruchamiasz programy/komendy i dostajesz tekst. PowerShell jest środowiskiem, w którym polecenia zwracają obiekty (ustrukturyzowane dane), które można dalej obrabiać. To fundament, który tłumaczy, czemu polecenia wyglądają inaczej.

Trzy praktyczne różnice:

• Cmdlety (np. Get-Process) mają spójną składnię i przewidywalne parametry.
• Obiekty zamiast tekstu: wynik ma właściwości (np. nazwa procesu, zużycie CPU, pamięć), a nie tylko „wydruk na ekran”.
• Pipeline (potok) „|”: możesz przekazać wynik jednego cmdletu do następnego bez ręcznego kopiowania i parsowania tekstu.

To dlatego PowerShell dobrze nadaje się do diagnozy i automatyzacji: nie tylko pokazuje, ale pozwala precyzyjnie filtrować, sortować i zapisywać wyniki.

Kiedy PowerShell ma sens, a kiedy GUI jest szybsze

Nie ma sensu „na siłę” używać konsoli do wszystkiego. Jeśli chcesz zmienić nazwę jednego pliku albo sprawdzić IP w Ustawieniach, GUI może być szybsze. PowerShell zaczyna wygrywać, gdy pojawia się skala albo powtarzalność.

Przykłady, gdzie PowerShell daje pierwsze „wygrane”:

• masowe wyszukanie dużych plików w folderze i posortowanie po rozmiarze,
• sprawdzenie, które procesy najbardziej obciążają CPU/pamięć,
• zebranie informacji o systemie i zapis do pliku (do wysłania komuś lub do własnej diagnozy),
• szybkie sprawdzenie statusu usług (bez przeklikiwania usług.msc).

Uruchamianie PowerShell w Windows 10/11: Terminal, klasyczny PowerShell i tryb administratora

Dwie drogi startu: Windows Terminal i „Windows PowerShell”

W Windows 11 (i coraz częściej także w Windows 10) naturalnym miejscem do pracy jest Windows Terminal. To aplikacja, która potrafi otwierać różne „profile” w kartach: PowerShell, CMD, WSL. Jest wygodniejsza w codziennym użyciu: lepsze kopiuj-wklej, przewijanie, karty, czytelniejsze czcionki.

Druga ścieżka to klasyczna aplikacja Windows PowerShell (zwykle PowerShell 5.1), którą znajdziesz w menu Start. W poradnikach nadal często pojawia się nazwa „Windows PowerShell”, bo była standardem przez lata i jest wbudowana w system.

Jeśli masz wybór: do nauki i codziennych poleceń wybierz Windows Terminal z profilem PowerShell. Jeśli instrukcja mówi wprost „Windows PowerShell” i wymaga elementów specyficznych dla 5.1, też dasz radę — składnia podstaw jest bardzo podobna.

Zwykła sesja vs podniesione uprawnienia (admin) — jak wybrać

„Uruchom jako administrator” oznacza uruchomienie PowerShell w kontekście konta z podniesionymi uprawnieniami (UAC). To jest potrzebne, gdy polecenie ma dotykać elementów chronionych: usług systemowych, sterowników, folderów typu C:Windows lub C:Program Files, ustawień globalnych systemu.

Konkretnie: admin zwykle jest potrzebny, gdy chcesz wykonać operacje typu Stop-Service / Restart-Service na usługach systemowych, zmiany w konfiguracji sieci, zapis do chronionych lokalizacji, modyfikacje rejestru w gałęziach systemowych. Do diagnostyki (Get-) najczęściej admin nie jest konieczny.

Dobry nawyk: nie pracuj cały czas jako admin. Uruchamiaj sesję z podniesionymi uprawnieniami dopiero wtedy, gdy widzisz, że operacja tego wymaga. To zmniejsza skutki ewentualnej pomyłki.

Jak sprawdzić, czy PowerShell działa jako administrator

Czasem tytuł okna sugeruje, że masz admina, ale lepiej umieć to sprawdzić poleceniem. Wpisz:

[Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()

To zwróci obiekt z informacjami o tożsamości. Żeby dostać prostą odpowiedź True/False, użyj:

([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

Jeśli wynik to True, sesja ma uprawnienia administratora. Jeśli False, działasz jako zwykły użytkownik.

Oswojenie konsoli: prompt, katalogi, autouzupełnianie, pomoc i „czytanie poleceń”

Prompt i bieżący katalog: gdzie jestem i na czym pracuję

Większość stresu wynika z tego, że w GUI widzisz foldery i przyciski, a w konsoli „nic”. W PowerShell podstawową rzeczą jest bieżący katalog (working directory). Sprawdzisz go tak:

Get-Location

Wejście do folderu działa przez:

Set-Location C:Users
Set-Location .Pobrane

Wiele osób używa cd — to alias na Set-Location. Na start to OK, ale dobrze wiedzieć, że „prawdziwa” nazwa cmdletu jest inna. Listowanie plików i folderów to:

Get-ChildItem
Get-ChildItem -Path C:Windows

Aliasami są dir i ls, ale one mogą mylić, bo wyglądają jak CMD/Linux. Jeśli uczysz się świadomie, przynajmniej przez chwilę używaj pełnych nazw cmdletów.

Ścieżki ze spacjami i cudzysłowy: najczęstsza mina

Jeśli ścieżka zawiera spacje, musisz ją ująć w cudzysłów:

Set-Location "C:Program Files"
Get-ChildItem "C:UsersJan KowalskiDocuments"

Tu przydaje się autouzupełnianie. Zacznij wpisywać ścieżkę i użyj TAB. PowerShell podpowie i często sam doda cudzysłowy, jeśli są potrzebne (zależnie od wersji i ustawień).

Wiele błędów typu „nie znaleziono ścieżki” wynika z tego, że PowerShell potraktował fragment po spacji jako kolejne argumenty. Jeśli coś dziwnie się rozjeżdża, pierwsza rzecz do sprawdzenia: czy ścieżka jest w cudzysłowie.

Autouzupełnianie i historia poleceń: małe usprawnienia, duży komfort

PowerShell jest używalny dopiero wtedy, gdy nie musisz wszystkiego pisać ręcznie. Minimum:

• TAB – autouzupełnianie cmdletów, parametrów i ścieżek,
• strzałka w górę / w dół – historia poleceń,
• Ctrl+L – czyści ekran (bez kasowania historii).

Tip: w wielu konfiguracjach (zwłaszcza w Windows Terminal) działa wyszukiwanie w historii przez Ctrl+R (to zależy od modułu PSReadLine i ustawień). Jeśli działa: wciskasz Ctrl+R i wpisujesz fragment polecenia, które wykonywałeś wcześniej.

Pomoc, która naprawdę działa: Get-Help, Get-Command i Get-Member

PowerShell ma wbudowaną pomoc. Najważniejsze, żeby nie czytać jej „od deski do deski”, tylko umieć wyciągnąć przykłady. Przykładowo:

Get-Help Get-Process -Examples

To najkrótsza droga do sensownego użycia cmdletu. Gdy potrzebujesz pełnej składni (parametry, typy), użyj:

Get-Help Get-Process -Full

Gdy nie pamiętasz nazwy polecenia, szukasz po czasowniku/rzeczowniku:

Get-Command -Verb Get
Get-Command -Noun Process
Get-Command *service*

Największa różnica między PowerShell a CMD ujawnia się w Get-Member. To cmdlet, który pokazuje, co właściwie „siedzi” w wyniku (jakie właściwości i metody ma obiekt):

Get-Process | Get-Member

Zobaczysz m.in. właściwości typu Name, CPU, Id. To potem wykorzystasz w sortowaniu i filtrowaniu.

Składnia bez magii: parametry, pipeline, filtrowanie i formatowanie wyników

Parametry i przełączniki: jak czytać polecenie przed Enterem

W PowerShell typowy schemat wygląda tak: cmdlet + parametry. Parametry zaczynają się od myślnika, np. -Name, -Path, -Recurse. To trochę jak „ustawienia” polecenia, tylko że wpisujesz je wprost.

Przykład:

Get-Service -Name wuauserv

Get-Service to cmdlet, -Name to parametr, a wuauserv to wartość parametru (nazwa usługi Windows Update). Jeśli wartość ma spacje, użyj cudzysłowu:

Get-Process -Name "WindowsTerminal"

Niektóre parametry są przełącznikami (switch): nie mają wartości, ich obecność zmienia zachowanie. Przykład z rekurencją:

Get-ChildItem -Path C:Temp -Recurse

Na start dobrze zapamiętać: -Recurse potrafi „rozlać” działanie na całą strukturę folderów, więc to parametr, który warto dodawać świadomie, a nie z rozpędu.

Pipeline (|): co płynie w potoku i czemu to ułatwia życie

Potok | przekazuje wynik jednego cmdletu do następnego. I teraz najważniejsze: w PowerShell w potoku płyną obiekty. Dzięki temu nie musisz „wycinać” tekstu jak w CMD, tylko pracujesz na właściwościach.

Klasyczny przykład „pierwszej wygranej”:

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

Co tu się dzieje, kawałek po kawałku:

Get-Process zwraca obiekty procesów. Sort-Object CPU sortuje po właściwości CPU. Select-Object wybiera, co chcesz zobaczyć (tu: 10 pierwszych rekordów i tylko wybrane kolumny). To jest bardzo „windowsowe” zadanie diagnostyczne, ale zrobione bez klikania w Menedżerze zadań.

Gdy nie wiesz, jak nazywa się właściwość (np. czy to CPU, WorkingSet, PM), wracasz do:

Get-Process | Get-Member

Filtrowanie i zawężanie: Where-Object oraz Select-Object w praktyce

Filtrujesz wtedy, gdy nie chcesz oglądać wszystkiego. Where-Object pozwala przepuścić tylko te obiekty, które spełniają warunek. Na przykład: pokaż usługi, które są zatrzymane:

Get-Service | Where-Object Status -eq 'Stopped'

Albo procesy, których nazwa zawiera fragment:

Get-Process | Where-Object Name -like '*chrome*'

Składnia -like używa gwiazdek jako wildcardów (maski). Gdy szukasz „zawiera”, najczęściej chcesz właśnie *fragment*. Uwaga: porównania tekstowe są domyślnie nieczułe na wielkość liter (case-insensitive), więc *Chrome* i *chrome* dadzą ten sam efekt.

Select-Object to z kolei zawężanie „po kolumnach” i czasem „po ilości”. Najprostszy trik w codziennym użyciu: najpierw filtruj, potem wybieraj właściwości. Przykład dla usług, które ruszają automatycznie, ale aktualnie nie działają:

Get-Service |
  Where-Object StartType -eq 'Automatic' |
  Where-Object Status -ne 'Running' |
  Select-Object Name, DisplayName, Status, StartType

To jest typowa sytuacja „coś nie wstało po restarcie”. Zamiast przeklikiwać listę w usługach, masz krótką listę podejrzanych.

Formatowanie wyników: Format-Table, Format-List i pułapka „formatowania w środku potoku”

Gdy wynik ma być czytelny dla człowieka, sięgasz po Format-Table (tabela) albo Format-List (lista). Dla procesów w tabelce:

Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Name, CPU, Id | Format-Table -AutoSize

A gdy obiekt ma sporo właściwości i chcesz je obejrzeć „na spokojnie”, lista jest wygodniejsza:

Get-Service -Name wuauserv | Format-List *

Uwaga: Format-* zostawiaj na sam koniec. Formatowanie zmienia dane w obiekty przeznaczone do wyświetlania, a wtedy dalsze filtrowanie/sortowanie potrafi zacząć zachowywać się „dziwnie”. Jeśli planujesz jeszcze obrabiać wynik, rób to przed Format-Table/Format-List.

Sortowanie i miary: Sort-Object, Measure-Object i szybka kontrola „ile tego jest”

Gdy chcesz szybko ustalić, co dominuje (np. które pliki są największe), sortowanie + selekcja daje natychmiastowy obraz:

Get-ChildItem C:Temp -File |
  Sort-Object Length -Descending |
  Select-Object -First 10 Name, Length

Measure-Object jest świetne do odpowiedzi na krótkie pytania: „ile?”, „jaka suma?”, „jaka średnia?”. Przykład: policz liczbę zatrzymanych usług:

(Get-Service | Where-Object Status -eq 'Stopped' | Measure-Object).Count

To drobiazg, ale daje pewność, czy filtr działa i czy skala problemu jest „jedna usługa” czy „kilkadziesiąt”.

Bezpieczna praca i minimalne ryzyko: „Get- przed Set-”, -WhatIf, a także Execution Policy

„Najpierw Get, potem Set”: nawyk, który ratuje skórę

Jeśli polecenie coś zmienia (Set-, Remove-, Stop-, Restart-), najpierw zrób „podgląd” wersją Get- i upewnij się, że trafiasz w dobry obiekt. Przykład z usługami: zanim zatrzymasz, wyświetl:

Get-Service -Name wuauserv

Dopiero gdy widzisz poprawną usługę i jej stan, idź dalej. Ten schemat jest banalny, ale redukuje większość wpadek typu „pomyliłem nazwę” albo „poleciało na całej liście”.

-WhatIf i -Confirm: symulacja zamiast zgadywania

Wiele cmdletów modyfikujących wspiera przełącznik -WhatIf, który nie wykonuje operacji, tylko opisuje, co by zrobił. To idealne przy masowych akcjach, np. sprzątaniu plików:

Symulacja sprzątania plików: -WhatIf w praktyce

Jeśli masz folder „do ogarnięcia” i chcesz usunąć np. stare logi, to jest dokładnie ten moment, kiedy -WhatIf robi robotę. Najpierw budujesz selekcję (czyli: co ma wylecieć), a dopiero potem przełączasz się na realne wykonanie.

Remove-Item -Path C:Temp*.log -WhatIf

Zobaczysz komunikaty w stylu „What if: Performing the operation…”, bez faktycznego kasowania. Gdy wszystko wygląda sensownie, dopiero wtedy odpalasz bez -WhatIf:

Remove-Item -Path C:Temp*.log

To samo dotyczy bardziej „masowych” akcji, np. usuwania plików rekurencyjnie. I tu uwaga: -Recurse + Remove-Item to zestaw, przy którym -WhatIf powinien być odruchem.

Remove-Item -Path C:TempOld -Recurse -Force -WhatIf

-Force pozwala usuwać m.in. ukryte/tylko do odczytu, więc jest wygodny, ale podnosi „siłę rażenia”. Jeśli po -WhatIf nadal masz wątpliwości, dołóż -Confirm i podejmuj decyzję krok po kroku:

Remove-Item -Path C:TempOld -Recurse -Force -Confirm

Skąd wiedzieć, czy cmdlet wspiera -WhatIf?

Nie każdy cmdlet ma -WhatIf. Wspierają go te, które implementują tzw. ShouldProcess (mechanizm potwierdzania operacji). Najprostszy test: sprawdź parametry w pomocy albo wylistuj je z Get-Help:

Get-Help Remove-Item -Full

Jeśli w sekcji parametrów jest -WhatIf i -Confirm, możesz robić bezpieczne „suche przebiegi”.

Uprawnienia: kiedy potrzebujesz „Uruchom jako administrator”, a kiedy nie

To, że konsola jest „czarna”, nie znaczy, że ma magiczne moce. PowerShell działa w granicach uprawnień procesu. Różnica między zwykłą sesją a administracyjną jest konkretna:

• w zwykłej sesji możesz bezpiecznie diagnozować i czytać większość informacji o systemie,
• w sesji administratora zyskujesz możliwość modyfikowania usług, niektórych ustawień systemowych, instalacji funkcji, zmian w rejestrze w chronionych gałęziach itp.

Jeśli instrukcja mówi „uruchom jako administrator”, to zwykle dlatego, że polecenie dotyka obszarów chronionych. Jeśli nie ma takiej potrzeby, trzymaj się zwykłej sesji — to naturalna „barierka bezpieczeństwa”.

Praktyczny test: jeśli polecenie kończy się błędem typu Access is denied albo Requested registry access is not allowed, wtedy dopiero rozważ admina. Nie odwrotnie.

Execution Policy: co to jest i czemu skrypt „nie chce się uruchomić”

Execution Policy (polityka uruchamiania) nie jest „antywirusem” i nie jest też twardym mechanizmem bezpieczeństwa. To bardziej zabezpieczenie przed przypadkowym uruchamianiem skryptów (np. pobranych z internetu) bez zrozumienia, co robią.

Gdy próbujesz uruchomić skrypt .ps1 i dostajesz komunikat o zablokowaniu, sprawdź aktualną politykę:

Get-ExecutionPolicy
Get-ExecutionPolicy -List

W praktyce najczęściej spotkasz:

• Restricted – skrypty zablokowane (da się pracować interaktywnie, ale nie odpalisz .ps1),
• RemoteSigned – lokalne skrypty działają, a pobrane z internetu wymagają podpisu lub odblokowania,
• AllSigned – wszystko musi być podpisane,
• Bypass – bez ograniczeń (do zastosowań specjalnych, nie jako domyślne).

Najmniej inwazyjne podejście to zmiana tylko dla bieżącej sesji (nie „na stałe” w systemie). Jeśli musisz jednorazowo uruchomić skrypt, ustaw politykę tylko dla procesu:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

To działa do zamknięcia okna PowerShell/Terminala. Potem wraca poprzedni stan.

Jeśli skrypt jest pobrany z internetu, Windows oznacza go tzw. Mark of the Web (strumień strefy). Zamiast luzować politykę, często wystarczy odblokować konkretny plik:

Unblock-File -Path .skrypt.ps1

Uwaga: Unblock-File nie „sprawdza bezpieczeństwa”. Ono usuwa blokadę. To Ty decydujesz, czy ufasz źródłu. Minimum higieny: otwórz skrypt w edytorze i przejrzyj, czy nie ma podejrzanych rzeczy typu pobieranie binarek, grzebanie w rejestrze, wyłączanie zabezpieczeń.

Uruchamianie skryptu: . i ścieżki ze spacjami

Typowy zgrzyt na starcie: wpisujesz nazwę skryptu i PowerShell mówi, że „nie znaleziono polecenia”. PowerShell domyślnie nie uruchamia plików z bieżącego katalogu po samej nazwie. Musisz wskazać ścieżkę względną:

.skrypt.ps1

Gdy ścieżka ma spacje, używaj cudzysłowów:

& "C:UsersJan KowalskiDesktopmoj skrypt.ps1"

Tu pojawia się & (operator wywołania). Przydaje się, kiedy uruchamiasz coś, co jest „w stringu” albo ma problematyczną ścieżkę.

Pierwsze komendy, które realnie ułatwiają życie w Windows 10/11

Pliki i foldery: szybkie wyszukiwanie, sortowanie i bezpieczny eksport

Jeśli do tej pory używałeś wyszukiwarki w Eksploratorze i „czasem działała”, to PowerShell bywa bardziej przewidywalny. Szukanie plików po rozszerzeniu i sortowanie po rozmiarze:

Get-ChildItem -Path C:Temp -File -Recurse -Filter *.log |
  Sort-Object Length -Descending |
  Select-Object -First 20 FullName, Length

Gdy wynik ma trafić do pliku (np. do zgłoszenia w IT), nie rób print-screenów. Zapisz listę:

Get-ChildItem -Path C:Temp -File -Recurse -Filter *.log |
  Sort-Object Length -Descending |
  Select-Object FullName, Length |
  Out-File -FilePath "$env:USERPROFILEDesktoplista-logow.txt" -Encoding utf8

$env:USERPROFILE to zmienna środowiskowa wskazująca katalog profilu użytkownika, więc ścieżka zadziała niezależnie od nazwy konta.

Procesy: znajdź, sprawdź, dopiero potem zamykaj

Najpierw diagnoza: co dokładnie działa, ile zużywa pamięci, jaki ma PID (Id procesu):

Get-Process -Name chrome |
  Select-Object Name, Id, CPU, WorkingSet

Jeśli musisz zakończyć proces, rób to świadomie. Najbezpieczniej po Id (PID), bo nazwa może pasować do wielu instancji:

Stop-Process -Id 12345 -WhatIf

Gdy -WhatIf pokazuje właściwy proces, dopiero wtedy bez symulacji:

Stop-Process -Id 12345

Uwaga: ubijanie procesu to „twarda” operacja — aplikacja może nie zapisać danych. Jeśli to coś krytycznego (np. proces systemowy), Windows i tak często odmówi bez odpowiednich uprawnień albo skończy się to niestabilnością.

Sieć: szybka diagnoza bez przeklikiwania ustawień

Do szybkiego sprawdzenia konfiguracji sieci (adresy IP, interfejsy) przydaje się:

Get-NetIPConfiguration

Gdy problem dotyczy „czy DNS działa”, często bardziej praktyczne od klasycznego ping jest testowanie konkretnego portu i hosta:

Test-NetConnection -ComputerName github.com -Port 443

Dostajesz czytelny wynik: czy jest połączenie TCP, jaki adres IP został użyty, gdzie jest problem. To dobry przykład „komendy, która wygląda groźnie, a jest tylko diagnostyczna”.

Usługi: stan, tryb uruchamiania i szybkie sprawdzenie zależności

Jeśli coś „nie działa po restarcie”, usługi są częstym podejrzanym. Stan i tryb uruchamiania:

Get-Service -Name wuauserv | Select-Object Name, Status, StartType

W samym Get-Service zależności są dostępne jako właściwości obiektu. Możesz je podejrzeć:

Get-Service -Name wuauserv | Select-Object -ExpandProperty ServicesDependedOn

To pomaga zrozumieć, czemu uruchomienie jednej usługi „nie idzie” — czasem blokuje ją coś niżej w łańcuchu.

PowerShell 5.1 vs PowerShell 7: co wybrać na start w Windows 10/11

Co już masz w systemie i czemu to zwykle wystarcza

Windows 10 i 11 mają wbudowany Windows PowerShell 5.1. Jest mocno zintegrowany z systemem i modułami administracyjnymi. Do nauki podstaw, diagnostyki, pracy na plikach/procesach/usługach — to jest w zupełności OK.

Wersję sprawdzisz tak:

$PSVersionTable

Kiedy ma sens doinstalować PowerShell 7

PowerShell 7 (czasem skracany do „PS7”) jest nowszy, szybszy w wielu scenariuszach i rozwijany niezależnie od Windows. Daje m.in. lepszą przenośność (działa też na macOS/Linux) i sporo usprawnień języka.

Na poziomie początkującym sens instalacji PS7 pojawia się zwykle wtedy, gdy:

• korzystasz z gotowych narzędzi/skryptów, które jawnie wymagają PowerShell 7,
• pracujesz w Windows Terminal i chcesz mieć „domyślnie najnowsze”,
• wchodzisz w automatyzację i chcesz uczyć się na tym, co jest aktualnie standardem w nowych projektach.

Jednocześnie dobrze wiedzieć o typowej pułapce: część „windowsowych” modułów administracyjnych była historycznie pisana pod 5.1 i nie zawsze działa identycznie w 7 (zależy od modułu). W praktyce wiele rzeczy jest już kompatybilnych, ale jeśli trafisz na konflikt, trzymanie pod ręką 5.1 jest normalne.

Rozsądny kolejny krok po pierwszych 30–60 minutach

Trzy nawyki, które najszybciej budują pewność

Gdy konsola przestaje stresować, dzieje się to zwykle nie przez znajomość stu komend, tylko przez kilka mechanizmów:

• zanim coś zmienisz: podgląd (Get-*, Select-Object) i ewentualnie -WhatIf,
• gdy nie wiesz „co zwraca” polecenie: Get-Member,
• gdy zgadujesz składnię: Get-Help ... -Examples i autouzupełnianie TAB.

To zamyka pętlę: rozumiesz wejście (parametry), widzisz wyjście (właściwości), a ryzyko zmian kontrolujesz (symulacja/potwierdzenia). Jeśli masz zrobić jeden praktyczny „mini-projekt”, to dobrym treningiem jest zebranie informacji (procesy/usługi/sieć) i zapisanie wyniku do pliku na pulpicie — bez żadnych zmian w systemie.

Najważniejsze punkty

• Najbezpieczniejszy start to zasada „najpierw odczyt, potem zmiana”: cmdlety z Get- zwykle tylko zbierają dane, a Set-/Remove-/Stop-/Restart-/New- realnie modyfikują system (uwaga: te drugie uruchamiaj dopiero, gdy rozumiesz efekt).
• Ryzyko nie wynika z „groźnej konsoli”, tylko z tempa działania — jedno polecenie potrafi zrobić to, co w GUI zajmuje kilka minut, więc czytanie komendy przed Enter to podstawowy nawyk bezpieczeństwa.
• Uprawnienia działają jak bezpiecznik: w sesji bez admina wiele wrażliwych operacji po prostu się nie wykona (komunikaty typu Access is denied), ale to nie zastępuje myślenia i testowania na mało inwazyjnych poleceniach.
• PowerShell różni się od CMD trzema rzeczami, które robią robotę w automatyzacji: spójne cmdlety, wyniki jako obiekty (ustrukturyzowane dane) oraz potok | do filtrowania/sortowania/przekazywania wyników bez „rzeźbienia” w tekście.
• GUI bywa szybsze przy pojedynczych akcjach, ale PowerShell wygrywa przy skali i powtarzalności — np. szybkie namierzenie dużych plików i sortowanie po rozmiarze, sprawdzenie „co żre” CPU/RAM, zebranie informacji o systemie do pliku, podgląd statusu usług bez klikania w services.msc.

Źródła informacji

• PowerShell Documentation. Microsoft Learn – Podstawy PowerShell: cmdlety, potok, Get-Help/Get-Command, aliasy, praca z obiektami.
• About Execution Policies. Microsoft – Wyjaśnia Execution Policy, tryby i wpływ na uruchamianie skryptów w Windows PowerShell.
• PowerShell 7.4 Documentation. PowerShell (GitHub project) – Różnice i cechy PowerShell 7 vs Windows PowerShell 5.1; instalacja i kompatybilność.
• Windows security: User Account Control (UAC). Microsoft Security – Zasady UAC i uruchamianie z podniesionymi uprawnieniami (Run as administrator).
• Windows 10 and Windows 11 security and identity documentation. Microsoft Docs – Kontekst uprawnień, konta i role; tło dla pracy jako admin vs użytkownik.