Kapitel 1 – Komma igång med PowerShell

Jag tycker ofta att presentatörer på konferenser och användargruppsmöten redan har PowerShell igång när de startar presentationer på startnivå. Den här boken börjar med att besvara de frågor jag har hört deltagare som inte tidigare har använt PowerShell fråga i dessa sessioner.

Mer specifikt fokuserar det här kapitlet på att hitta och starta PowerShell och lösa några av de första smärtpunkterna som nya användare upplever med PowerShell. Se till att följa med och gå igenom exemplen som visas i det här kapitlet på din Windows 10-labbmiljödator.

Vad behöver jag för att komma igång med PowerShell?

Alla moderna versioner av Windows-operativsystem levereras med PowerShell installerat. Om du kör en version som är äldre än 5.1 bör du installera den senaste versionen.

• Information om hur du uppgraderar till Windows PowerShell 5.1 finns i Uppgradera befintliga Windows PowerShell
• Information om hur du installerar den senaste versionen av PowerShell finns i Installera PowerShell

Var hittar jag PowerShell?

Det enklaste sättet att hitta PowerShell på Windows 10 är att skriva PowerShell i sökfältet enligt bild 1–1.

Observera att fyra olika genvägar för PowerShell visas i bild 1–1. Datorn som används i demonstrationssyfte i den här boken kör 64-bitarsversionen av Windows 10, så det finns en 64-bitarsversion av PowerShell-konsolen och PowerShell ISE (integrerad skriptmiljö) och en 32-bitarsversion av var och en som anges av suffixet (x86) på genvägarna. Om du råkar köra en 32-bitarsversion av Windows 10 har du bara två genvägar. Dessa objekt har inte suffixet (x86), men de är 32-bitarsversioner. Om du har ett 64-bitars operativsystem rekommenderar jag att du kör 64-bitarsversionen av PowerShell om du inte har en specifik orsak till att köra 32-bitarsversionen.

Information om hur du startar PowerShell på andra versioner av Windows finns i Starta Windows PowerShell.

Hur gör jag för att starta PowerShell?

I de företagsmiljöer för produktion som jag stöder använder jag tre olika Active Directory-användarkonton. Jag har speglat kontona i labbmiljön som används i den här boken. Jag loggar in på Windows 10-datorn som en domänanvändare som inte är domän eller lokal administratör.

Jag har startat PowerShell-konsolen genom att klicka på genvägen "Windows PowerShell" enligt bild 1-1.

Observera att namnlisten i PowerShell-konsolen säger "Windows PowerShell" enligt bild 1–4. Vissa kommandon fungerar bra, men PowerShell kan inte delta i användaråtkomstkontroll (UAC). Det innebär att det inte går att fråga efter utökade behörigheter för uppgifter som kräver godkännande av en administratör. Följande felmeddelande genereras:

Get-Service -Name W32Time | Stop-Service

Stop-Service : Service 'Windows Time (W32Time)' cannot be stopped due to the following
error: Cannot open W32Time service on computer '.'.
At line:1 char:29
+ Get-Service -Name W32Time | Stop-Service
+
    + CategoryInfo          : CloseError: (System.ServiceProcess.ServiceController:ServiceController)
     [Stop-Service], ServiceCommandException
    + FullyQualifiedErrorId : CouldNotStopService,Microsoft.PowerShell.Commands.StopServiceCommand

Lösningen på det här problemet är att köra PowerShell som en domänanvändare som är lokal administratör. Så här konfigureras mitt andra domänanvändarkonto. Med principen om minsta behörighet bör det här kontot INTE vara domänadministratör eller ha utökade privilegier i domänen.

Stäng PowerShell. Starta om PowerShell-konsolen, förutom att högerklicka på Windows PowerShell-genvägen den här gången och välj Kör som administratör enligt bild 1–5.

Om du är inloggad i Windows som en vanlig användare uppmanas du att ange autentiseringsuppgifter. Jag anger autentiseringsuppgifterna för mitt användarkonto som är domänanvändare och lokal administratör enligt bild 1–6.

När PowerShell har återlanserats som administratör bör namnlisten säga "Administratör: Windows PowerShell" enligt bild 1–7.

Nu när PowerShell körs förhöjt som lokal administratör är UAC inte längre ett problem när ett kommando körs på den lokala datorn som normalt kräver en uppmaning om utökade privilegier. Tänk dock på att alla kommandon som körs från den här upphöjda instansen av PowerShell-konsolen också körs förhöjda.

För att förenkla sökningen av PowerShell och starta det som administratör rekommenderar jag att du fäster det i aktivitetsfältet och anger att det ska startas automatiskt som administratör varje gång det körs.

Sök efter PowerShell igen, förutom den här gången högerklickar du på det och väljer "Fäst i aktivitetsfältet" enligt bild 1–8.

Högerklicka på den PowerShell-genväg som nu är fäst i aktivitetsfältet och välj egenskaper enligt bild 1–9.

Klicka på "Avancerat" som anges av #1 i bild 1-10, markera sedan kryssrutan "Kör som administratör" som anges av #2 i bild 1-10 och klicka sedan på OK två gånger för att acceptera ändringarna och avsluta båda dialogrutorna.

Du behöver aldrig bekymra dig om att hitta PowerShell eller om det körs som administratör igen.

Att köra PowerShell upphöjd som administratör för att förhindra problem med UAC påverkar endast kommandon som körs mot den lokala datorn. Det påverkar inte kommandon som riktar sig mot fjärrdatorer.

Vilken version av PowerShell kör jag?

Det finns ett antal automatiska variabler i PowerShell som lagrar tillståndsinformation. En av dessa variabler är $PSVersionTable, som innehåller en hashtable som kan användas för att visa relevant PowerShell-versionsinformation:

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19041.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Nyare versioner av Windows PowerShell distribueras som en del av Windows Management Framework (WMF). En specifik version av .NET Framework krävs beroende på WMF-versionen. Information om hur du uppgraderar till Windows PowerShell 5.1 finns i Uppgradera befintliga Windows PowerShell.

Körningsprincip

I motsats till vad många tror är körningsprincipen i PowerShell inte en säkerhetsgräns. Den är utformad för att förhindra att en användare omedvetet kör ett skript. En bestämd användare kan enkelt kringgå körningsprincipen i PowerShell. Tabell 1–2 visar standardkörningsprincipen för aktuella Windows-operativsystem.

Windows-operativsystemversion	Standardkörningsprincip
Server 2019	Fjärrsignerad
Server 2016	Fjärrsignerad
Windows 10	Begränsad

Oavsett körningsprincipinställningen kan alla PowerShell-kommandon köras interaktivt. Körningsprincipen påverkar endast kommandon som körs i ett skript. Cmdleten Get-ExecutionPolicy används för att avgöra vad den aktuella körningsprincipinställningen är och cmdleten Set-ExecutionPolicy används för att ändra körningsprincipen. Min rekommendation är att använda remotesigned-principen , som kräver att nedladdade skript signeras av en betrodd utgivare för att kunna köras.

Kontrollera den aktuella körningsprincipen:

Get-ExecutionPolicy

Restricted

PowerShell-skript kan inte köras alls när körningsprincipen är inställd på Begränsad. Det här är standardinställningen för alla Windows-klientoperativsystem. Om du vill demonstrera problemet sparar du följande kod som en .ps1 fil med namnet Stop-TimeService.ps1.

Dricks

Ett PowerShell-skript är en klartextfil med ett .ps1 tillägg som innehåller de kommandon som du vill köra. Om du vill skapa ett PowerShell-skript använder du en kodredigerare som Visual Studio Code (VS Code) eller någon textredigerare som Anteckningar.

Get-Service -Name W32Time | Stop-Service -PassThru

Det kommandot körs interaktivt utan fel så länge PowerShell körs förhöjt som administratör. Men så fort det sparas som en skriptfil och du försöker köra skriptet genererar det ett fel:

.\Stop-TimeService.ps1

.\Stop-TimeService.ps1 : File C:\demo\Stop-TimeService.ps1 cannot be loaded because
running scripts is disabled on this system. For more information, see
about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\Stop-TimeService.ps1
+
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Observera att felet som visas i föregående resultatuppsättning visar exakt vad problemet är (skript som körs är inaktiverade i det här systemet). När du kör ett kommando i PowerShell som genererar ett felmeddelande bör du läsa felmeddelandet i stället för att bara köra kommandot igen och hoppas att det körs.

Ändra PowerShell-körningsprincipen till fjärrsignerad.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution
policy might expose you to the security risks described in the about_Execution_Policies help topic
at http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):y

Läs varningen som visas när du ändrar körningsprincipen. Jag rekommenderar också att du tar en titt på about_Execution_Policies hjälpavsnittet för att se till att du förstår säkerhetskonsekvenserna av att ändra körningsprincipen.

Nu när körningsprincipen har angetts till RemoteSigned körs skriptet Stop-TimeService.ps1 utan fel.

.\Stop-TimeService.ps1

Status   Name               DisplayName
------   ----               -----------
Stopped  W32Time            Windows Time

Var noga med att starta windows-tidstjänsten innan du fortsätter, annars kan du stöta på oförutsedda problem.

Start-Service -Name w32time

Sammanfattning

I det här kapitlet har du lärt dig hur du hittar och startar PowerShell och hur du skapar en genväg som startar PowerShell som administratör. Du har också lärt dig om standardkörningsprincipen och hur du ändrar den.

Granskning

1. Hur avgör du vilken PowerShell-version en dator kör?
2. Varför är det viktigt att starta PowerShell upphöjt som administratör?
3. Hur avgör du den aktuella PowerShell-körningsprincipen?
4. Vad förhindrar standardprincipen för PowerShell-körning på Windows-klientdatorer från att inträffa?
5. Hur ändrar du PowerShell-körningsprincipen?

Rekommenderad läsning

För dem som vill veta mer information om de ämnen som beskrivs i det här kapitlet rekommenderar jag att du läser följande PowerShell-hjälpavsnitt.

• about_Automatic_Variables
• about_Hash_Tables
• about_Execution_Policies

I nästa kapitel får du lära dig mer om det går att identifiera kommandon i PowerShell. En av de saker som kommer att omfattas är hur du uppdaterar PowerShell så att dessa hjälpämnen kan visas direkt från PowerShell i stället för att behöva visa dem på Internet.