What`s New in Windows PowerShell 4.0 (nb-NO) - TechNet Articles - United States (English) - TechNet Wiki

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 Wiragment-6615">

What`s New in Windows PowerShell 4.0 (nb-NO)

  • 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:

 

image

 

Alle eksemplene over vil produsere samme resultat:

image

 

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

 

image

 

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

clip_image001

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:

clip_image003

 

  • Get-Module viser nå versjons-informasjon:

clip_image005

 

  • 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:

clip_image007

 

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:

image

 

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:

image  

image

 

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

 

image

 

 

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).