Utviklingen av PowerShell startet tilbake i 2002 med Jeffrey Snover`s visjon om hvordan management av Windows skal bli i fremtiden. Denne visjonen er beskrevet i Monad Manifesto (Monad var kodenavnet for det som senere ble navngitt Windows PowerShell). De overordnede funksjonene nedskrevet i manifestet:

• Monad Automation Model (v1)
• Monad Shell (v1)
• Monad Remote Scripting (v2)
• Monad Management Console (v3)
• Monad Management Models (v4)

Helt siden Windows PowerShell 1.0 har vi sett at det gradvis har kommet mer funksjonalitet, og at det i hver versjon har kommet en eller flere større features (for eksempel Remoting i versjon 2.0) som bygger videre på den opprinnelige visjonen. I Windows PowerShell 4.0, som er en del av Windows 8.1 og Windows Server 2012 R2, introduseres den siste byggestenen i visjonen – Desired State Configuraton (kalt “Monad Management Models” i manifestet).

Produktet er på ingen måte komplett, det vil alltid være behov for feilretting og ny funksjonalitet, men de grunnleggende byggestenene er nå på plass. I resten av denne artikkelen skal vi se nærmere på nyheter i Windows PowerShell 4.0.

Hva er nytt i Windows PowerShell 4.0?

Dette er ikke en komplett oversikt, men et utvalg av de største nyhetene:

• Execution policy – innstillingen som sier om scriptkjøring er tillatt – har tidligere vært satt til Restricted som standard. Det vil si at man enten har måttet endre execution policy manuelt eller via Group Policy før man kan kjøre et PowerShell-script. Nytt i Windows Server 2012 R2 er at execution policy er satt til RemoteSigned som standard. På klient-siden (Windows 8.1) er standard execution policy fremdeles Restricted.

• Common parameters i PowerShell er parametre som er tilgjengelig på alle cmdlets, et eksempel er –ErrorAction som typisk settes til «stop» dersom man skal sette opp en try catch blokk for feilhåndtering. I PowerShell 4.0 har vi fått en ny common parameter som heter PipelineVariable. Denne parameteren lar oss lagre resultatet fra en pipet kommando som en variabel vi definerer navnet på selv. I PowerShell 1.0/2.0 hadde vi $_ som pekte til «gjeldende objekt i pipeline», i PowerShell 3.0 fikk vi den nye $PSItem variabelen som ga samme funksjonalitet. Den nye PipelineVariable parameteren gir oss enda mer fleksibilitet. Her er 3 eksempler som viser enkel bruk av PipelineVariable sammenlignet med tidligere versjoner:

Alle eksemplene over vil produsere samme resultat:

Her er et annet eksempel som viser hvordan PipelineVariable kan benyttes av senere kommandoer i pipeline:

• Get-Process har fått en ny switch parameter, IncludeUserName:

Tidligere var ikke UserName en del av objekter produsert av Get-Process, men noen man måtte beregne selv om man hadde behov for det.

• En ny cmdlet, Get-FileHash, som viser hash informasjon for filer er lagt til:

• Get-Module viser nå versjons-informasjon:

• Register-ScheduledJob og Set-ScheduledJob har fått en RunNow parameter, som gjør at man ikke lenger behøver å sette et umiddelbart startstidspunkt for jobber ved å bruke Trigger-parameteren.

• Save-Help introdusert i PowerShell 3.0 gjør det mulig å lagre hjelpe-filer for en PowerShell modul, for å distribuere den til andre maskiner som for eksempel ikke har internett-tilgang. I versjon 3.0 måtte modulene man ville laste ned hjelpe-filer for være installert lokalt på maskinen man kjørte Save-Help fra. I versjon 4.0 er det mulig å lagre hjelperfiler for en modul selv om den ikke er installert på lokal maskin. Eksempel: 

Nyheter i Windows PowerShell Integrated Scripting Environment (ISE)

• Windows PowerShell ISE har fått støtte for både Windows PowerShell Workflow debugging og remote script debugging.
• Det er lagt til IntelliSense støtte for Windows PowerShell Desired State Configuration, eksempel:

Nyheter i Windows PowerShell Workflow

• Det er nå mulig å benytte throttling for aktiviteten Foreach -Parallel ved å bruke den nye egenskapenThrottleLimit.
• ErrorAction som er en common parameter har fått en ny gyldig verdi, Suspend, som er eksklusiv for workflows.

Nyheter i Windows PowerShell Web Access

• Det er nå mulig å koble fra og koble til på nytt mot eksisterende sesjoner i det web-baserte PowerShell Web Access konsollet. En ny Save-knapp i konsollet lar oss koble fra en sesjon, noe som gjør det mulig å koble til den samme sesjonen på nytt på et senere tidspunkt.
• Det er nå mulig å ha flere PowerShell Web Access sesjoner i samme nettleser sesjon ved å benytte flere faner. Det er ikke lenger nødvending å åpne en ny nettleser sesjon for å koble til flere sesjoner mot PowerShell Web Access.

I dette eksempelet ser vi to PowerShell Web Access sesjoner i samme nettleser sesjon:

Trykker man på den nye Save-knappen får man en melding som sier at det er mulig å koble til sesjonen på et senere tidspunkt:

Dersom man logger inn på nytt mot samme server får man valget om å koble til eksisterende sesjon eller opprette en ny sesjon:

Feilrettinger

Det er også utført en rekke feilrettinger i PowerShell 4.0:

• Statmentet #Requires gjør det nå mulig å angi at det er nødvendig med administrative rettigheter
• Import-Csv ignorerer nå blanke linjer
• Et problem hvor Windows PowerShell ISE bruker for mye mine ved bruk av Invoke-WebRequest er rettet
• Select-Object –Expand feiler ikke lenger dersom verdien av angitt egenskap er tom ($null).
• Get-Job returnerer nå alle fullførte schedulerte jobber, også i nye PowerShell sesjoner.
• Et problem med mounting og unmounting av VHD-filer i filsystem provideren i PowerShell 4.0 er løst. PowerShel er nå i stand til å detektrere når nye enheter mountes i samme sesjon.
• Det er ikke lenger nødvendig å eksplisitt laste ScheduledJob eller Workflow modulene for å håndtere scheduled jobs og workflow jobs med for eksempel Get-Job.

De fleste feilrettinger er utført basert på tilbakemeldinger fra PowerShell-brukere. Dersom du finner feil eller har forslag til ny funksjonalitet kan du rapportere disse på Microsoft Connect. Hvordan dette gjøres kan du lese om i denne artikkelen.

Windows PowerShell Desired State Configuration

Windows PowerShell Desired State Configuration (DSC) er den desidert største nyheten i Windows PowerShell 4.0. DSC gjør det mulig å administrere og rulle ut konfigurasjoner til en eller flere maskiner. Et eksempel kan være en konfigurasjon som sier at server-rollen IIS skal være installert. Dersom IIS ikke er installert på en ny maskin hvor en DSC-konfigurasjon sier at IIS skal være installert, vil DSC sørge for at IIS installeres. DSC vil også re-installere IIS dersom rollen manuelt av-installeres av en administrator. Dette gjør det enklere å standardisere konfigurasjon på nye maskiner samt unngå såkalt “configuration drift” på eksisterende maskiner. Du kan lese mer om DSC i TechNet Wiki-artikkelen Introduction to Windows PowerShell Desired State Configuration (nb-NO).