Hemsida » hur » Geek School Lär dig hur du automatiserar Windows med PowerShell

    Geek School Lär dig hur du automatiserar Windows med PowerShell

    I den här utgåvan av Geek School hjälper vi dig att förstå det kraftfulla PowerShell-skriptspråket som är byggt direkt i Windows, och är mycket användbart att veta i en IT-miljö.

    Medan denna serie inte är strukturerad runt en tentamen, är lärande PowerShell en av de viktigaste sakerna du kan göra som nätverksadministratör, så om det finns en sak du vill lära dig att hjälpa din IT-karriär, så är det här. Dessutom är det mycket roligt.

    Introduktion

    PowerShell är det mest kraftfulla automatiseringsverktyget som Microsoft har att erbjuda, och det är både ett skal och ett skriptspråk.

    Observera att denna serie är baserad på PowerShell 3, som skickas med Windows 8 och Server 2012. Om du kör Windows 7, ladda ner PowerShell 3-uppdateringen innan du fortsätter.

    Möt konsolen och ISE

    Det finns två sätt att interagera med PowerShell ur lådan, konsolen och den integrerade skriptmiljön - även känd som ISE. ISE har förbättrats avsevärt från den hemska versionen som skickades med PowerShell 2 och kan öppnas genom att trycka på Win + R-tangentkombinationen för att få fram en körruta och sedan skriva in powershell_ise och trycka på enter.

    Som du kan se ISE-sporten en delad vy så att du snabbt kan skript medan du fortfarande kan se resultatet i den lägre halvan av ISE. Den nedersta halvan av ISE, där resultaten av ditt skript skrivs ut, kan också användas som en REPL-prompt - ungefär som kommandotolken. V3 ISE lade slutligen till stöd för intellisens både i manusrutan och i den interaktiva konsolen.

    Alternativt kan du interagera med PowerShell med PowerShell Console, vilket jag brukar använda för den mesta av denna serie. PowerShell Console beter sig som kommandotolken - du anger helt enkelt kommandon och spetsar resultaten. För att öppna Windows PowerShell Console trycker du på Win + R-tangentkombinationen igen för att öppna en körruta och skriva powerhell och tryck sedan på enter.

    REPL prompts så här är fantastiskt för omedelbar tillfredsställelse: du anger ett kommando och du får resultat. Medan konsolen inte erbjuder intellisense, erbjuder den något som kallas flikavslutning som fungerar mycket lika - helt enkelt börja skriva ett kommando och tryck på fliken för att gå igenom möjliga matchningar.

    Använda hjälpsystemet

    I tidigare versioner av PowerShell inkluderades hjälpfiler när du installerade Windows. Detta var en bra lösning för det mesta men lämnade oss med ett stort problem. När PowerShells hjälpteam var tvungen att sluta arbeta med hjälpfilerna var PowerShell-utvecklarna fortfarande upptagna och kodade och gjorde ändringar. Detta innebar att när PowerShell skickades var hjälpfilerna felaktiga eftersom de inte innehöll de nyare ändringarna som gjordes i koden. För att lösa detta problem levereras PowerShell 3 utan hjälpfiler i rutan och innehåller ett uppdaterbart hjälpsystem. Det betyder att innan du gör någonting så vill du ladda ner de senaste hjälpfilerna. Du kan göra det genom att öppna en PowerShell Console och köra:

    Update-Help

    Grattis till att du kör ditt första PowerShell-kommando! Sanningen är att kommandot Update-Help har många fler alternativ än att bara köra det, och för att se dem vill vi se hjälpen för kommandot. För att visa hjälpen för ett kommando, skickar du helt enkelt namnet på det kommando du vill ha hjälp med till parametern Namn i kommandot Get-Help, till exempel:

    Get-Help-Name Update-Help

    Du undrar nog hur du tolkar all den texten ändå, jag menar varför finns det två mängder information under syntaxavsnittet och varför finns det så många fästen överallt? Första saker först: anledningen till att det finns två informationsblock under syntaxavsnittet är att de representerar olika sätt att köra kommandot. Dessa är tekniskt kallade parametersatser och du kan bara använda en åt gången (du kan inte blanda parametrar från olika uppsättningar). I ovanstående skärmdump kan du se att toppparametersatsen har en SourcePath-parameter medan botten inte gör det. Anledningen till att du skulle använda toppparametersatsen (den som innehåller SourcePath) om du uppdaterade dina hjälpfiler från en annan maskin i ditt nätverk som redan har laddat ner dem, medan du inte behöver ange en källväg om du ville bara ta de senaste filerna från Microsoft.

    För att svara på den andra frågan finns det en viss syntax som hjälper till med att följa och här är det:

    • Fyrkantiga parenteser runt ett parameternamn och dess typ betyder att det är en valfri parameter och kommandot fungerar bra utan det.
    • Fyrkantiga parenteser runt parameterns namn betyder att parametrarna är positionsparametrar.
    • Saken till höger om en parameter i de vinklade fästena berättar vilken datatyp parametern förväntar sig.

    Medan du borde lära dig att läsa hjälpfilens syntax, om du någonsin är osäker på en viss parameter, lägg bara till - Fyll i slutet av ditt kommando för hjälp och rulla ner till parameterns avsnitt, där det kommer att berätta lite mer om varje parameter.

    Get-Help-Name Update-Help-Fullständig

    Det sista du behöver veta om hjälpsystemet är hur du kan använda den för att upptäcka kommandon, vilket är mycket enkelt. Du förstår, PowerShell accepterar jokertecken nästan var som helst, så att använda dem tillsammans med kommandot Get-Help gör att du enkelt kan upptäcka kommandon. Till exempel letar jag efter kommandon som handlar om Windows Services:

    Få-hjälp-namn * service *

    Visst kan all denna information inte vara bra för fladdermusen, men lita på mig, ta dig tid och lär dig hur du använder hjälpsystemet. Det kommer till hands hela tiden, även till avancerade scripters som har gjort det här i flera år.

    säkerhet

    Detta skulle inte vara en korrekt introduktion utan att nämna säkerhet. Den största oro för PowerShell-teamet är att PowerShell blir den senaste och största attackpunkten för manuskriptkiddier. De har infört några säkerhetsåtgärder för att se till att det inte händer, så låt oss ta en titt på dem.

    Den mest grundläggande skyddsformen kommer från att PS1-filtillägget (tillägget som används för att beteckna ett PowerShell-skript) inte är registrerat hos en PowerShell-värd, det är faktiskt registrerat med anteckningsblock. Det betyder att om du dubbelklickar på en fil öppnas den med anteckningsblock istället för att springa.

    För det andra kan du inte köra skript från skalet genom att bara skriva skriptets namn, du måste ange hela sökvägen till skriptet. Så om du vill köra ett manus på din C-enhet skulle du behöva skriva:

    C: \ runme.ps1

    Eller om du redan är i kärnan på C-enheten kan du använda följande:

    .\ runme.ps1

    Slutligen har PowerShell något som heter Execution Policies, vilket hindrar dig från att bara köra ett gammalt manus. Faktum är att du som standard inte kan köra några skript och behöver ändra din exekveringspolicy om du vill få köra dem. Det finns 4 anmärkningsvärda genomförandepolicyer:

    • begränsad: Detta är standardkonfigurationen i PowerShell. Den här inställningen innebär att inget script kan köra, oavsett signatur. Det enda som kan köras i PowerShell med denna inställning är ett enskilt kommando.
    • AllSigned: Den här inställningen tillåter att skript körs i PowerShell. Skriptet måste ha en tillhörande digital signatur från en betrodd utgivare. Det kommer att bli en snabb innan du kör skript från betrodda utgivare.
    • RemoteSigned: Den här inställningen tillåter att skript körs, men kräver att skript och konfigurationsfiler som laddas ned från Internet har en tillhörande digital signatur från en betrodd utgivare. Skript som körs från den lokala datorn behöver inte signeras. Det finns inga anvisningar innan du kör skriptet.
    • Obegränsad: Det gör det möjligt att skicka osignerade skript, inklusive alla skript och konfigurationsfiler som laddas ner från Internet. Detta kommer att innehålla filer från Outlook och Messenger. Risken här kör skript utan signatur eller säkerhet. Vi recommenced att du aldrig oss denna inställning.

    För att se vad din nuvarande Exekveringspolicy är inställd på, öppna en PowerShell Console och skriv:

    Get-ExecutionPolicy

    För den här kursen och de flesta andra omständigheter är RemoteSigned Policy det bästa, så fortsätt och ändra din policy med hjälp av följande.

    Obs! Det här måste göras från en förhöjd PowerShell Console.

    Set-ExecutionPolicy RemoteSigned

    Det är allt för den här gången, vi ses i morgon för lite mer PowerShell-kul.


    Ansvarsbegränsning: Den korrekta termen för ett PowerShell-kommando är en cmdlet, och från och med nu kommer vi att använda den här rätt terminologin. Det kände sig bara lämpligare att kalla dem kommandon för denna introduktion.


    Om du har några frågor kan du tweeta mig @taybgibb, eller bara lämna en kommentar.