Geek School Lær hvordan du automatiserer Windows med PowerShell

I denne utgaven av Geek School vil vi hjelpe deg med å forstå det kraftige PowerShell skriptspråk som er bygget rett inn i Windows, og er ekstremt nyttig å vite i et IT-miljø.

Selv om denne serien ikke er strukturert rundt en eksamen, er læring PowerShell en av de viktigste tingene du kan gjøre som nettverksadministrator, så hvis det er en ting du vil lære å hjelpe din IT-karriere, er dette det. I tillegg er det mye moro.

Introduksjon

PowerShell er det kraftigste automatiseringsverktøyet som Microsoft har å tilby, og det er både et skall og et skriptspråk.

Vær oppmerksom på at denne serien er basert på PowerShell 3, som leveres med Windows 8 og Server 2012. Hvis du kjører Windows 7, laster du ned PowerShell 3-oppdateringen før du fortsetter.

Møt konsollen og ISE

Det er to måter å interagere med PowerShell ut av boksen, konsollen og det integrerte skriptmiljøet - også kjent som ISE. ISE har vesentlig forbedret seg fra den heslige versjonen som ble levert med PowerShell 2, og kan åpnes ved å trykke på Win + R-tastaturkombinasjonen for å hente en kjørebok, deretter skrive powershell_ise og trykke enter.

Som du kan se ISE-sporten, er en delt visning slik at du raskt kan skript mens du fortsatt kan se resultatet i den nederste halvdelen av ISE. Den nederste halvdelen av ISE, der resultatene av skriptet skrives ut, kan også brukes som en REPL-ledetekst - omtrent som kommandoprompt. V3 ISE til slutt lagt til støtte for intellisense i både manuskriptruten og den interaktive konsollen.

Alternativt kan du kommunisere med PowerShell ved hjelp av PowerShell Console, som jeg vil bruke for det meste av denne serien. PowerShell Console oppfører seg mye som kommandoprompten - du bare skriver inn kommandoer og spytter ut resultatene. Hvis du vil åpne Windows PowerShell Console, trykker du igjen på Win + R-tastaturkombinasjonen for å åpne en kjøreboks og skrive powershell og trykk deretter enter.

REPL prompts som dette er fantastisk for øyeblikkelig tilfredstillelse: du skriver inn en kommando og du får resultater. Mens konsollen ikke tilbyr intellisense, tilbyr det noe som kalles tabulasjon, som fungerer mye det samme - bare start å skrive en kommando og trykk på fanen for å bla gjennom mulige kamper.

Bruke hjelpesystemet

I tidligere versjoner av PowerShell ble hjelpefiler inkludert når du installerte Windows. Dette var en god løsning for det meste, men ga oss et betydelig problem. Når PowerShells hjelpeteam måtte slutte å jobbe med hjelpefilene, var PowerShell-utviklerne fremdeles opptatt av koding og endringer. Dette betydde at når PowerShell ble sendt, var hjelpefilene feil fordi de ikke inneholdt de nyere endringene som ble gjort til koden. For å løse dette problemet, kommer PowerShell 3 uten hjelpefiler ut av boksen og inneholder et oppdaterbart hjelpesystem. Dette betyr at før du gjør noe du vil laste ned de nyeste hjelpefilene. Du kan gjøre det ved å åpne en PowerShell Console og kjøre:

Update-Help

Gratulerer med å kjøre din første PowerShell-kommando! Sannheten er at oppdateringshjelp-kommandoen har mange flere muligheter enn bare å kjøre den, og for å se dem vil vi se hjelpen til kommandoen. For å se hjelpen til en kommando, passerer du bare navnet på kommandoen du vil ha hjelp til til parameternavnet i kommandoen Get-Help, for eksempel:

Hent-Hjelp-Navn Oppdateringshjelp

Du lurer nok på hvordan du tolker all den teksten uansett, jeg mener hvorfor er det to mye informasjon under syntaksdelen og hvorfor er det så mange braketter over alt? Første ting først: grunnen til at det er to blokker med informasjon under syntakseksjonen, er fordi de representerer forskjellige måter å kjøre kommandoen på. Disse er teknisk kalt parameter sett og du kan bare bruke en om gangen (du kan ikke blande parametere fra forskjellige sett). I det ovennevnte skjermbildet kan du se at toppparametersettet har en SourcePath-parameter mens bunnen ikke gjør det. Årsaken er at du vil bruke toppparametersettet (den som inkluderer SourcePath) hvis du oppdaterte hjelpefilene fra en annen maskin på nettverket ditt som allerede hadde lastet ned dem, mens du ikke trenger å spesifisere en kildebane hvis du ville bare ta tak i de nyeste filene fra Microsoft.

For å svare på det andre spørsmålet, er det en viss syntaks som hjelper filene følger og her er det:

Firkantede parenteser rundt et parameternavn og dets type betyr at det er en valgfri parameter, og kommandoen vil fungere fint uten det.
Firkantede parenteser rundt parameternavn betyr at parametrene er posisjonsparameter.
Tingen til høyre for en parameter i de vinklede parentesene forteller deg datatypen som parameteren forventer.

Mens du bør lære å lese hjelpefilsyntaxen, hvis du noen gang er usikker på en bestemt parameter, bare legg til -Full til slutten av din kommando for hjelp og bla ned til parameter-delen, der den vil fortelle deg litt mer om hver parameter.

Get-Help -Name Update-Help-Fullt

Det siste du trenger å vite om hjelpesystemet er hvordan du kan bruke den til å oppdage kommandoer, noe som egentlig er veldig enkelt. Du ser, PowerShell aksepterer jokertegn nesten hvor som helst, så bruk dem sammen med kommandoen Get-Help lar deg enkelt oppdage kommandoer. For eksempel ser jeg etter kommandoer som omhandler Windows Services:

Få-hjelp-navn * tjeneste *

Sikker på at all denne informasjonen kanskje ikke er nyttig for flaggermusen, men stol på meg, ta deg tid og lær hvordan du bruker hjelpesystemet. Det kommer til nytte hele tiden, selv til avanserte scripters som har gjort dette i årevis.

Sikkerhet

Dette ville ikke være en riktig introduksjon uten å nevne sikkerhet. Den største bekymringen for PowerShell-teamet er at PowerShell blir det nyeste og største angrepspunktet for skriptkiddier. De har satt noen få sikkerhetstiltak på plass for å sikre at dette ikke skjer, så la oss ta en titt på dem.

Den mest grunnleggende beskyttelsesformen kommer fra at PS1-filtypen (utvidelsen som brukes til å betegne et PowerShell-skript) ikke er registrert hos en PowerShell-vert, det er faktisk registrert med Notisblokk. Det betyr at hvis du dobbeltklikker på en fil, vil den åpne med notisblokk i stedet for å kjøre.

For det andre kan du ikke kjøre skript fra skallet ved å bare skrive skriptets navn, du må angi hele banen til skriptet. Så hvis du ønsker å kjøre et skript på C-stasjonen din, må du skrive:

C: \ runme.ps1

Eller hvis du allerede er på roten til C-stasjonen, kan du bruke følgende:

.\ runme.ps1

Endelig har PowerShell noe som heter Execution Policies, som stopper deg fra å bare kjøre et gammelt skript. Faktisk kan du som standard ikke kjøre noen skript og må endre din utførelsespolicy hvis du vil ha lov til å kjøre dem. Det er 4 bemerkelsesverdige utførelsesretningslinjer:

begrenset: Dette er standardkonfigurasjonen i PowerShell. Denne innstillingen betyr at ingen skript kan kjøre, uavhengig av signaturen. Det eneste som kan kjøres i PowerShell med denne innstillingen er en individuell kommando.
AllSigned: Denne innstillingen tillater at skript kjøres i PowerShell. Skriptet må ha en tilhørende digital signatur fra en klarert utgiver. Det vil bli spørsmål før du kjører skriptene fra klarerte utgivere.
RemoteSigned: Denne innstillingen tillater at skript kjøres, men krever at skript og konfigurasjonsfiler som lastes ned fra Internett, har en tilhørende digital signatur fra en klarert utgiver. Skript som kjører fra den lokale datamaskinen trenger ikke å bli signert. Det er ingen anrop før du kjører skriptet.
Ubegrenset: Dette tillater at ikke-signerte skript kjøres, inkludert alle skript og konfigurasjonsfiler som er lastet ned fra Internett. Dette vil inkludere filer fra Outlook og Messenger. Risikoen her kjører skript uten signatur eller sikkerhet. Vi recommenced at du aldri oss denne innstillingen.

Hvis du vil se hva din nåværende utførelsespolicy er satt til, åpner du en PowerShell Console og skriver inn:

Get-ExecutionPolicy

For dette kurset og de fleste andre omstendigheter er RemoteSigned Policy det beste, så fortsett og endre retningslinjene dine ved å bruke følgende.

Merk: Dette må gjøres fra en forhøyet PowerShell Console.

Set-ExecutionPolicy RemoteSigned

Det er alt for denne gangen folk, ser deg i morgen for litt mer PowerShell-moro.

Ansvarsfraskrivelse: Den rette termen for en PowerShell-kommando er en cmdlet, og fra nå av vil vi bruke denne riktige terminologien. Det føltes bare mer hensiktsmessig å kalle dem kommandoer for denne introduksjonen.

Hvis du har noen spørsmål, kan du tweet meg @ taybgibb, eller bare gi en kommentar.