通过

Nyheter i Windows PowerShell 4.0

  • 项目

Det er ikke lenge siden jeg skrev artikkelen Introduksjon til Windows PowerShell 3.0 her på TechNet Norge`s blog, og allerede nå er neste versjon tilgjengelig. Tiden mellom lansering av nye operativsystem hos Microsoft, som dermed også gjelder Windows PowerShell siden det er en del av operativsystemet, blir mindre og mindre. Dette er èn av konskekvensene av at Microsoft nå har blitt en skytjeneste leverandør med fokus på Software + Services. Dette innebærer en ny utviklingsmodell hvor tempoet er høyere enn tidligere. Endringene i Windows 8.1 og Windows Server 2012 R2 er utviklet på under ett år, noe som viser at utviklingen har foregått i et veldig høyt tempo.

Det er også interessant å se tilbake på tingenes tilstand da jeg skrev artikkelen Windows PowerShell – hva det er og hvorfor det er viktig for deg som ITPro tilbake i 2010 da det var et halvår siden forrige operativsystem lansering (RTM Juli 2009). I ettertid ser vi at det skulle gå hele 3 år før en ny versjon ble lansert (RTM August 2012).

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:

 

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 egenskapen ThrottleLimit.
  • 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

 

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 minne 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. PowerShell 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 og se praktiske eksempler i min neste artikkel her på TechNet Norge`s blog som vil publiseres om kort tid.

 

Ressurser

 

Comments

  • Anonymous
    January 01, 2003
    thank you