Geek School Lær at automatisere Windows med PowerShell

I denne udgave af Geek School hjælper vi dig med at forstå det kraftfulde PowerShell script sprog, der er bygget direkte ind i Windows, og er yderst nyttigt at kende i en IT-miljø.

Mens denne serie ikke er struktureret omkring en eksamen, er Learning PowerShell en af de vigtigste ting, du kan gøre som netværksadministrator, så hvis der er en ting, du vil lære at hjælpe din it-karriere, så er det det. Plus, det er meget sjovt.

Introduktion

PowerShell er det mest kraftfulde automatiseringsværktøj, som Microsoft har at byde på, og det er både en shell og et skriptsprog.

Bemærk venligst, at denne serie er baseret på PowerShell 3, som leveres med Windows 8 og Server 2012. Hvis du kører Windows 7, skal du downloade PowerShell 3-opdateringen, inden du fortsætter.

Mød konsollen og ISE

Der er to måder at interagere med PowerShell ud af boksen, Console og Integrated Scripting Environment - også kendt som ISE. ISE'en er blevet væsentligt forbedret fra den hæslige version, der blev leveret med PowerShell 2, og den kan åbnes ved at trykke på Win + R tastaturkombinationen for at hente en kørselsboks og derefter skrive powershell_ise og trykke enter.

Som du kan se ISE sporten en split visning, så du kan hurtigt script mens du stadig kan se resultatet i den nederste halvdel af ISE. Den nederste halvdel af ISE, hvor resultaterne af dit script udskrives, kan også bruges som en REPL-prompt - ligesom kommandoprompt. V3 ISE tilføjede endelig support til intellisense i både scriptpanelet og den interaktive konsol.

Alternativt kan du interagere med PowerShell ved hjælp af PowerShell Console, hvilket jeg vil bruge til de fleste af denne serie. PowerShell Console opfører sig meget ligesom kommandoprompten - du indtaster simpelthen kommandoer, og det spytter resultaterne ud. For at åbne Windows PowerShell Console skal du trykke igen på Win + R-tastaturkombinationen for at åbne en kørselsboks og skrive powershell og derefter trykke enter.

REPL prompts som dette er fantastisk til øjeblikkelig tilfredsstillelse: du indtaster en kommando, og du får resultater. Mens konsollen ikke tilbyder intellisense, tilbyder den noget, der hedder fanebladet, som fungerer meget det samme - bare start at skrive en kommando og tryk på fanen for at cykle gennem mulige kampe.

Brug af hjælpesystemet

I tidligere versioner af PowerShell blev hjælpefiler inkluderet, da du installerede Windows. Dette var en god løsning for det meste, men efterlod os et stort problem. Da PowerShells hjælperete måtte stoppe med at arbejde med hjælpefilerne, var PowerShell-udviklerne stadig optaget af kodning og ændringer. Dette betød, at når HjælpShell blev sendt, var hjælpefilerne forkerte, fordi de ikke indeholdt de nyere ændringer, der var blevet foretaget til koden. For at løse dette problem leveres PowerShell 3 uden hjælpefiler ud af kassen og indeholder et opdaterbart hjælpesystem. Det betyder, før du gør noget, du vil downloade de nyeste hjælpefiler. Du kan gøre det ved at åbne en PowerShell Console og køre:

Opdatering-Help

Tillykke med at køre din første PowerShell-kommando! Sandheden er, at kommandoen Update-Help har mange flere muligheder end blot at køre den, og for at se dem vil vi gerne se hjælp til kommandoen. For at se hjælpen til en kommando, skal du blot sende navnet på den kommando, du vil have hjælp til til parameternavnet i kommandoen Få hjælp, for eksempel:

Få Hjælp-Navn Update-Hjælp

Du spekulerer nok på, hvordan du alligevel tolker al den tekst. Jeg mener, hvorfor er der to masser af oplysninger under syntaksafsnittet, og hvorfor er der så mange parenteser overalt? Første ting først: Årsagen til, at der er to blokke af information under syntaksafsnittet, er, at de repræsenterer forskellige måder at køre kommandoen på. Disse kaldes teknisk set parametersæt, og du kan kun bruge en ad gangen (du kan ikke blande parametre fra forskellige sæt). I ovenstående skærmbillede kan du se, at det øverste parameter sæt har en SourcePath-parameter, mens bunden ikke gør det. Årsagen er, at du vil bruge topparametersættet (den der indeholder SourcePath), hvis du opdaterede dine hjælpefiler fra en anden maskine på dit netværk, der allerede har downloadet dem, mens du ikke behøver at angive en kildevej, hvis du ville bare tage de nyeste filer fra Microsoft.

For at besvare det andet spørgsmål er der en vis syntaks, der hjælper filer, der følger, og her er det:

Firkantede parenteser omkring et parameternavn og dets type betyder, at det er en valgfri parameter, og kommandoen vil fungere fint uden det.
Firkantede parenteser omkring parametrene betyder, at parametrene er positionsparameter.
Sagen til højre for en parameter i de vinklede parenteser fortæller den datatype, parameteren forventer.

Mens du bør lære at læse hjælpefiltsyntaxen, hvis du nogensinde er usikker på en bestemt parameter, skal du blot tilføje -Fuld til slutningen af din få hjælp-kommando og rul ned til parameterafsnittet, hvor det vil fortælle dig lidt mere om hver parameter.

Get-Help -Name Update-Help -Full

Det sidste du skal vide om hjælpesystemet er, hvordan du kan bruge det til at opdage kommandoer, hvilket faktisk er meget nemt. Du ser, PowerShell accepterer jokertegn næsten hvor som helst, så brug af dem sammen med kommandoen Get-Help gør det nemt at opdage kommandoer. For eksempel leder jeg efter kommandoer, der omhandler Windows Services:

Få-Hjælp-Navn * Service *

Sikker på, at alle disse oplysninger måske ikke er nyttige til flagermus, men tro mig, tag dig tid og lære at bruge hjælpesystemet. Den kommer hele tiden til nytte, selv til avancerede scripters, der har gjort dette i årevis.

Sikkerhed

Dette ville ikke være en ordentlig introduktion uden at nævne sikkerhed. Den største bekymring for PowerShell-teamet er, at PowerShell bliver det seneste og største angrebspunkt for scriptkiddies. De har sat nogle få sikkerhedsforanstaltninger på plads for at sikre, at dette ikke sker, så lad os tage et kig på dem.

Den mest grundlæggende form for beskyttelse skyldes, at PS1 filtypen (den udvidelse der bruges til at betegne et PowerShell script) ikke er registreret hos en PowerShell vært, det er faktisk registreret med Notesblok. Det betyder, at hvis du dobbeltklikker på en fil, åbnes det med notesblok i stedet for at køre.

For det andet kan du ikke køre scripts fra skallen ved blot at skrive scriptets navn, du skal angive den fulde sti til scriptet. Så hvis du ønskede at køre et script på dit C-drev, skulle du skrive:

C: \ runme.ps1

Eller hvis du allerede er i roden til C-drevet, kan du bruge følgende:

.\ runme.ps1

Endelig har PowerShell noget, der hedder Execution Policies, som stopper dig fra at bare køre et gammelt script. Faktisk kan du som standard ikke køre nogle scripts og skal ændre din udførelsespolitik, hvis du vil have lov til at køre dem. Der er 4 bemærkelsesværdige gennemførelsesbestemmelser:

begrænset: Dette er standardkonfigurationen i PowerShell. Denne indstilling betyder, at intet script kan køre, uanset dets underskrift. Det eneste der kan køres i PowerShell med denne indstilling er en individuel kommando.
AllSigned: Denne indstilling tillader, at scripts kører i PowerShell. Skriften skal have en tilknyttet digital signatur fra en betroet udgiver. Der vil være en hurtig, før du kører scripts fra betroede udgivere.
RemoteSigned: Denne indstilling tillader scripts at køre, men kræver, at script- og konfigurationsfiler, der hentes fra internettet, har en tilknyttet digital signatur fra en betroet udgiver. Skripter, der kører fra den lokale computer, behøver ikke at blive underskrevet. Der er ingen beskeder, før du kører scriptet.
Ubegrænset: Dette tillader, at usignerede scripts kører, herunder alle scripts og konfigurationsfiler, der er hentet fra internettet. Dette vil omfatte filer fra Outlook og Messenger. Risikoen her kører scripts uden signatur eller sikkerhed. Vi recommenced at du aldrig os denne indstilling.

For at se, hvad din nuværende gennemførelsespolitik er indstillet, skal du åbne en PowerShell Console og skrive:

Get-ExecutionPolicy

For dette kursus og de fleste andre omstændigheder er RemoteSigned Policy den bedste, så fortsæt og ændre din politik ved hjælp af følgende.

Bemærk: Dette skal gøres fra en forhøjet PowerShell Console.

Set-ExecutionPolicy RemoteSigned

Det er alt for denne gang folk, vi ses i morgen for nogle flere PowerShell sjov.

Ansvarsfraskrivelse: Det korrekte udtryk for en PowerShell-kommando er en cmdlet, og fra nu af vil vi bruge denne korrekte terminologi. Det var bare mere hensigtsmæssigt at kalde dem kommandoer til denne introduktion.

Hvis du har spørgsmål, kan du tweet mig @taybgibb, eller bare forlade en kommentar.